CORRECTED 
VERSION* 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) Internationa! Patent Classification 6 : 
G06F 



A2 



(11) International Publication Number: WO 96/27155 

(43) International Publication Date: 6 September 1996 (06.09.96) 



(21) International Application Number: PCT/US96/02303 

(22) International Filing Date: 13 February 1996 (13.02.96) 



(30) Priority Data: 
08/388,107 



13 February 1995 (13.02.95) US 



(71) Applicant: ELECTRONIC PUBLISHING RESOURCES, INC. 

[US/US]; 5203 Battery Lane, Bethesda, MD 20814 (US). 

(72) Inventors: GINTER, Karl, L.; 10404 43rd Avenue, Beltsville, 

MD 20705 (US). SHEAR, Victor, H.; 5203 Battery Lane, 
Bethesda, MD 20814 (US). SPAHN, Francis, J.; 2410 
Edwards Avenue, El Cerrito, CA 94530 (US). VAN WIE, 
David, M.; 1250 Lakeside Drive, Sunnyvale, CA 94086 
(US). 

(74) Agent: FARIS, Robert, Nixon & Vanderhye P.C., 1100 
North Glebe Road, Arlington, VA 22201-4714 (US). 



(81) Designated States: AL, AM, AT, AU, AZ, BB, BG, BR, BY, 
CA, CH, CN, CZ, DE, DK, EE, ES, FI, GB, GE, HU, IS, 
JP, KE, KG, KP, KR, KZ, LK, LR, LS, LT. LU, LV, MD, 
MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, 
SE, SG, SI, SK, TJ, TM, TR, IT, UA, UG, UZ, VN, ARIPO 
patent (KE, LS, MW, SD, SZ, UG), Eurasian patent (AZ, 
BY, KG, KZ, RU, TJ, TM), European patent (AT, BE, CH, 
DE, DK, ES, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), 
OAPI patent (BF, BJ, CF, CG, CI, CM, GA, GN, ML, MR, 
NE, SN, TD, TG). 



Published 

Without international search report and to be republished 
upon receipt of that report. 



(54) Title: SYSTEMS AND METHODS FOR SECURE TRANSACTION MANAGEMENT AND ELECTRONIC RIGHTS PROTEC- 
TION 

(57) Abstract 

The present invention provides systems and methods for electronic commerce including secure transaction management and electronic 
rights protection. Electronic appliances such as computers employed in accordance with the present invention help to ensure that information 
is accessed and used only in authorized ways, and maintain the integrity, availability, and/or confidentiality of the information. Secure 
subsystems used with such electronic appliances provide a distributed virtual distribution environment (VDE) that may enforce a secure 
chain of handling and control, for example, to control and/or meter or otherwise monitor use of electronically stored or disseminated 
information. Such a virtual distribution environment may be used to protect rights of various participants in electronic commerce and other 
electronic or electronic-facilitated transactions. Secure distributed and other operating system environments and architectures, employing, for 
example, secure semiconductor processing arrangements mat may establish secure, protected environments at each node. These techniques 
may be used to support an end-to-end electronic information distribution capability that may be used, for example, utilizing the "electronic 
highway". 



BEST AVAILABLE COPY 



• (Referred to in PCT Gazette No. 52/1996, Section II) 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international 
applications under the PCT. 



AM 


Armenia 


GB 


United Kingdom 


MW 


Malawi 


AT 


Austria 


GE 


Georgia 


MX 


Mexico 


AU 


Australia 


GN 


Guinea 


NB 


Niger 


BB 


Barbados 


GR 


Greece 


NL 


Netherlands 


BE 


Belgium 


HU 


Hungary 


NO 


Norway 


BF 


Burkina Faso 


IE 


Ireland 


NZ 


New Zealand 


BG 


Bulgaria 


IT 


Italy 


PL 


Poland 


BJ 


Benin 


JP 


Japan 


PT 


Portugal 


BR 


Brazil 


KE 


Kenya 


RO 


Romania 


BY 


Belarus 


KG 


Kyrgystan 


RU 


Russian Federation 


CA 


Canada 


KP 


Democratic People's Republic 


SD 


Sudan 


CF 


Central African Republic 




of Korea 


SE 


Sweden 


CG 


Congo 


KR 


Republic of Korea 


SG 


Singapore 


CH 


Switzerland 


KZ 


Kazakhstan 


SI 


Slovenia 


a 


Cote d'lvoire 


LI 


Liechtenstein 


SK 


Slovakia 


CM 


Cameroon 


LK 


Sri Lanka 


SN 


Senegal 


CN 


China 


LR 


Liberia 


sz 


Swaziland 


CS 


Czechoslovakia 


LT 


Lithuania 


TD 


Chad 


cz 


Czech Republic 


LU 


I jmemboox^g 


TG 


Togo 


DE 


Germany 


LV 


Latvia 


TJ 


.Tajikistan 


DK 


Denmark 


MC 


Monaco 


TT 


Trinidad and Tobago 


EE 


Estonia 


MD 


Republic of Moldova 


UA 


Ukraine 


ES 


Spain 


MG 


Madagascar 


UG 


Uganda 


FI 


Finland 


ML 


Mah 


US 


United States of America 


FR 


France 


MN 


Mongolia 


uz 


Uzbekistan 


GA 


Gabon 


MR 




VN 


Viet Nam 



WO 96/27155 



PCT/US96/02303 



SYSTEMS AND METHODS FOR SECURE TRANSACTION 
MANAGEMENT AND ELECTRONIC RIGHTS PROTECTION 



Fiel4(s) of the Inyentiop(p) 



This invention generally relates to computer and/or 
electronic security. 

5 

More particularly, this invention relates to systems and 
techniques for secure transaction management. This invention 
also relates to computer-based and other electronic appliance- 
based technologies that help to ensure that information is 
10 accessed and/or otherwise used only in authorized ways, and 

maintains the integrity, availability, and/or confidentiality of 
such information and processes related to such use. 



The invention also relates to systems and methods for 
15 protecting rights of various participants in electronic commerce 

and other electronic or electronically-facilitated transactions. 



The invention also relates to secure chains of handling and 
control for both information content and information employed to 
20 regulate the use of such content and consequences of such use. It 

also relates to systems and techniques that manage, including 
meter and/or limit and/or otherwise monitor use of electronically 
stored and/or disseminated information. The invention 
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particularly relates to transactions, conduct and arrangements 
that make use of, including consequences of use of, such systems 
and/or techniques. 



10 



The invention also relates to distributed and other 
operating systems, environments and architectures. It also 
generally relates to secure architectures, including, for example, 
tamper-resistant hardware-based processors, that can be used to 
establish security at each node of a distributed system. 



Background and Summary of the Invention(s) 

Telecommunications, financial transactions, government 
processes, business operations, entertainment, and personal 
business productivity all now depend on electronic appliances. 

15 Millions of these electronic appliances have been electronically 

connected together. These interconnected electronic appliances 
comprise what is increasingly called the "information highway." 
Many businesses, academicians, and government leaders are 
concerned about how to protect the rights of citizens and 

20 organizations who use this information (also "electronic" or 

"digital") highway. 

Electronic Content 

Today, virtually anything that can be represented by 
25 words, numbers, graphics, or system of commands and 
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instructions can be formatted into electronic digital information. 
Television, cable, satellite transmissions, and on-line services 
transmitted over telephone lines, compete to distribute digital 
information and entertainment to homes and businesses. The 
owners and marketers of this content include software 
developers, motion picture and recording companies, publishers 
of books, magazines, and newspapers, and information database 
providers. The popularization of on-line services has also enabled 
the individual personal computer user to participate as a content 
provider. It is estimated that the worldwide market for electronic 
information in 1992 was approximately $40 billion and is 
expected to grow to $200 billion by 1997, according to Microsoft 
Corporation. The present invention can materially enhance the 
revenue of content providers, lower the distribution costs and the 
costs for content, better support advertising and usage 
information gathering, and better satisfy the needs of electronic 
information users. These improvements can lead to a significant 
increase in the amount and variety of electronic information and 
the methods by which such information is distributed. 

The inability of conventional products to be shaped to the 
needs of electronic information providers and users is sharply in 
contrast to the present invention. Despite the attention devoted 
by a cross-section of America's largest telecommunications, 
computer, entertainment and information provider companies to 
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some of the problems addressed by the present invention, only 
the present invention provides commercially secure, effective 
solutions for configurable, general purpose electronic commerce 
transaction/distribution control systems. 

Controlling Electronic Content 

The present invention provides a new kind of "virtual 
distribution environment" (called "VDE" in this document) that 
secures, administers, and audits electronic information use. VDE 
also features fundamentally important capabilities for managing 
content that travels "across 77 the "information highway * These 
capabilities comprise a rights protection solution that serves all 
electronic community members. These members include content 
creators and distributors, financial service providers, end-users, 
and others. VDE is the first general purpose, configurable, 
transaction control/rights protection solution for users of 
computers, other electronic appliances, networks, and the 
information highway. 

A fundamental problem for electronic content providers is 
extending their ability to control the use of proprietary 
information. Content providers often need to limit use to 
authorized activities and amounts. Participants in a business 
model involving, for example, provision of movies and advertising 
on optical discs may include actors, directors, script and other 



writers, musicians, studios, publishers, distributors, retailers, 
advertisers, credit card services, and content end-users. These 
participants need the ability to embody their range of agreements 
and requirements, including use limitations, into an "extended" 
agreement comprising an overall electronic business model. This 
extended agreement is represented by electronic content control 
information that can automatically enforce agreed upon rights 
and obligations. Under VDE, such an extended agreement may 
comprise an electronic contract involving all business model 
participants. Such an agreement may alternatively, or in 
addition, be made up of electronic agreements between subsets of 
the business model participants. Through the use of VDE, 
electronic commerce can function in the same way as traditional 
commerce — that is commercial relationships regarding products 
and services can be shaped through the negotiation of one or 
more agreements between a variety of parties. 

Commercial content providers are concerned with ensuring 
proper compensation for the use of their electronic information. 
Electronic digital information, for example a CD recording, can 
today be copied relatively easily and inexpensively. Similarly, 
unauthorized copying and use of software programs deprives 
rightful owners of billions of dollars in annual revenue according 
to the International Intellectual Property Alliance. Content 
providers and distributors have devised a number of limited 
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function rights protection mechanisms to protect their rights. 
Authorization passwords and protocols, license servers, 
"lock/unlock" distribution methods, and non-electronic 
contractual limitations imposed on users of shrink-wrapped 
software are a few of the more prevalent content protection 
schemes. In a commercial context, these efforts are inefficient 
and limited solutions. 

Providers of "electronic currency" have also created 
protections for their type of content. These systems are not 
sufficiently adaptable, efficient, nor flexible enough to support 
the generalized use of electronic currency. Furthermore, they do 
not provide sophisticated auditing and control configuration 
capabilities. This means that current electronic currency tools 
lack the sophistication needed for many real-world financial 
business models. VDE provides means for anonymous currency 
and for "conditionally* anonymous currency, wherein currency 
related activities remain anonymous except under special 
circumstances. 

VDE Control Capabilities 

VDE allows the owners and distributors of electronic 
digital information to reliably bill for, and securely control, audit, 
and budget the use of, electronic information. It can reliably 
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detect and monitor the use of commercial information products. 
VDE uses a wide variety of different electronic information 
delivery means: including, for example, digital networks, digital 
broadcast, and physical storage media such as optical and 
magnetic disks. VDE can be used by major network providers, 
hardware manufacturers, owners of electronic information, 
providers of such information, and clearinghouses that gather 
usage information regarding, and bill for the use of, electronic 
information. 

VDE provides comprehensive and configurable transaction 
management, metering and monitoring technology. It can 
change how electronic information products are protected, 
marketed, packaged, and distributed. When used, VDE should 
result in higher revenues for information providers and greater 
user satisfaction and value. Use of VDE will normally result in 
lower usage costs, decreased transaction costs, more efficient 
access to electronic information, re-usability of rights protection 
and other transaction management implementations, greatly 
improved flexibility in the use of secured information, and 
greater standardization of tools and processes for electronic 
transaction management. VDE can be used to create an 
adaptable environment that fulfills the needs of electronic 
information owners, distributors, and users; financial 
clearinghouses; and usage information analyzers and resellers. 
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Rights and Control Information 

In general, the present invention can be used to protect the 
rights of parties who have: 

5 (a) proprietary or confidentiality interests in electronic 

information. It can, for example, help ensure that 
information is used only in authorized ways; 

(b) financial interests resulting from the use of 

10 electronically distributed information. It can help 

ensure that content providers will be paid for use of 
distributed information; and 

(c) interests in electronic credit and electronic currency 
15 storage, communication, and/or use including 

electronic cash, banking, and purchasing. 

Protecting the rights of electronic community members 
involves a broad range of technologies. VDE combines these 

20 technologies in a way that creates a "distributed" electronic 

rights protection "environment." This environment secures and 
protects transactions and other processes important for rights 
protection. VDE, for example, provides the ability to prevent, or 
impede, interference with and/or observation of, important rights 

25 related transactions and processes. VDE, in its preferred 
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embodiment, uses special purpose tamper resistant Secure 
Processing Units (SPUs) to help provide a high level of security 
for VDE processes and information storage and communication. 

The rights protection problems solved by the present 
invention are electronic versions of basic societal issues. These 
issues include protecting property rights, protecting privacy 
rights, properly compensating people and organizations for their 
work and risk, protecting money and credit, and generally 
protecting the security of information. VDE employs a system 
that uses a common set of processes to manage rights issues in 
an efficient, trusted, and cost-effective way. 

VDE can be used to protect the rights of parties who create 
electronic content such as, for example: records, games, movies, 
newspapers, electronic books and reference materials, personal 
electronic mail, and confidential records and co mmuni cations. 
The invention can also be used to protect the rights of parties 
who provide electronic products, such as publishers and 
distributors; the rights of parties who provide electronic credit 
and currency to pay for use of products, for example, credit 
clearinghouses and banks; the rights to privacy of parties who 
use electronic content (such as consumers, business people, 
governments); and the privacy rights of parties described by 
electronic information, such as privacy rights related to 
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information contained in a medical record, tax record, or 
personnel record. 

In general, the present invention can protect the rights of 
parties who have: 

(a) commercial interests in electronically distributed 
information - the present invention can help ensure, 
for example, that parties, will be paid for use of 
distributed information in a manner consistent with 
their agreement; 

(b) proprietary and/or confidentiality interests in 
electronic information — the present invention can, 
for example, help ensure that data is used only in 
authorized ways; 

(c) interests in electronic credit and electronic currency 
storage, communication, and/or use - this can 
include electronic cash, banking, and purchasing; 
and 

(d) interests in electronic information derived, at least 
in part, from use of other electronic information. 

VDE Functional Properties 
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VDE is a cost-effective and efficient rights protection 
solution that provides a unified, consistent system for securing 
and managing transaction processing. VDE can: 

(a) audit and analyze the use of content, 

(b) ensure that content is used only in authorized ways, 
and 

(c) allow information regarding content usage to be used 
only in ways approved by content users. 

In addition, VDE: 

(a) is very configurable, modifiable, and re-usable; 

(b) supports a wide range of useful capabilities that may 
be combined in different ways to accommodate most 
potential applications; 

(c) operates on a wide variety of electronic appliances 
ranging from hand-held inexpensive devices to large 
mainframe computers; 
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(d) is able to ensure the various rights of a number of 
different parties, and a number of different rights 
protection schemes, simultaneously; 



(e) is able to preserve the rights of parties through a 
series of transactions that may occur at different 
times and different locations; 



(f) is able to flexibly accommodate different ways of 

securely delivering information and reporting usage; 
and 



(g) provides for electronic analogues to "real" money and 
credit, including anonymous electronic cash, to pay 
for products and services and to support personal 
(including home) banking and other financial 
activities. 



VDE economically and efficiently fulfills the rights 
protection needs of electronic community members. Users of 
VDE will not require additional rights protection systems for 
different information highway products and rights problems — nor 
will they be required to install and learn a new system for each 
new information highway application. 
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VDE provides a unified solution that allows all content 
creators, providers, and users to employ the same electronic 
rights protection solution. Under authorized circumstances, the 
participants can freely exchange content and associated content 
control sets. This means that a user of VDE may, if allowed, use 
the same electronic system to work with different kinds of 
content having different sets of content control information. The 
content and control information supplied by one group can be 
used by people who normally use content and control information 
supplied by a different group. VDE can allow content to be 
exchanged "universally" and users of an implementation of the 
present invention can interact electronically without fear of 
incompatibilities in content control, violation of rights, or the 
need to get, install, or learn a new content control system. 

The VDE securely administers transactions that specify 
protection of rights. It can protect electronic rights including, for 
example: 

(a) the property rights of authors of electronic content, 

(b) the commercial rights of distributors of content, 

(c) the rights of any parties who facilitated the 
distribution of content, 
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(d) the privacy rights of users of content, 

(e) the privacy rights of parties portrayed by stored 
and/or distributed content, and 

(f) any other rights regarding enforcement of electronic 
agreements. 

VDE can enable a very broad variety of electronically enforced 
commercial and societal agreements. These agreements can 
include electronically implemented contracts, licenses, laws, 
regulations, and tax collection. 

Contrast With Traditional Solutions 

Traditional content control mechanisms often require users 
to purchase more electronic information than the user needs or 
desires. For example, infrequent users of shrink-wrapped 
software are required to purchase a program at the same price as 
frequent users, even though they may receive much less value 
from their less frequent use. Traditional systems do not scale 
cost according to the extent or character of usage and traditional 
systems can not attract potential customers who find that a fixed 
price is too high. Systems using traditional mechanisms are also 
not normally particularly secure. For example, shrink-wrapping 
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does not prevent the constant illegal pirating of software once 
removed from either its physical or electronic package. 

Traditional electronic information rights protection 
systems are often inflexible and inefficient and may cause a 
content provider to choose costly distribution channels that 
increase a product's price. In general these mechanisms restrict 
product pricing, configuration, and marketing flexibility. These 
compromises are the result of techniques for controlling 
information which cannot accommodate both different content 
models and content models which reflect the many, varied 
requirements, such as content delivery strategies, of the model 
participants. This can limit a provider's ability to deliver 
sufficient overall value to justify a given product's cost in the eyes 
of many potential users. VDE allows content providers and 
distributors to create applications and distribution networks that 
reflect content providers' and users' preferred business models. 
It offers users a uniquely cost effective and feature rich system 
that supports the ways providers want to distribute information 
and the ways users want to use such information. VDE supports 
content control models that ensure rights and allow content 
delivery strategies to be shaped for maximum commercial results. 
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Chain of Handling and Control 

VDE can protect a collection of rights belonging to various 
parties having in rights in, or to, electronic information. This 
information may be at one location or dispersed across (and/or 
moving between) multiple locations. The information may pass 
through a "chain" of distributors and a "chain" of users. Usage 
information may also be reported through one or more "chains" of 
parties. In general, VDE enables parties that (a) have rights in 
electronic information, and/or (b) act as direct or indirect agents 
for parties who have rights in electronic information, to ensure 
that the moving, accessing, modifying, or otherwise using of 
information can be securely controlled by rules regarding how, 
when, where, and by whom such activities can be performed. 

VDE Applications and Software 

VDE is a secure system for regulating electronic conduct 
and commerce. Regulation is ensured by control information put 
in place by one or more parties. These parties may include 
content providers, electronic hardware manufacturers, financial 
service providers, or electronic "infrastructure* companies such 
as cable or telecommunications companies. The control 
information implements "Rights Applications * Rights 
applications "run on" the "base software" of the preferred 
embodiment. This base software serves as a secure, flexible, 
general purpose foundation that can accommodate many 
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different rights applications, that is, many different business 
models and their respective participant requirements. 

A rights application under VDE is made up of special 
purpose pieces, each of which can correspond to one or more basic 
electronic processes needed for a rights protection environment. 
These processes can be combined together like building blocks to 
create electronic agreements that can protect the rights, and may 
enforce fulfillment of the obligations, of electronic information 
users and providers. One or more providers of electronic 
information can easily combine selected building blocks to create 
a rights application that is unique to a specific content 
distribution model. A group of these pieces can represent the 
capabilities needed to fulfill the agreements) between users and 
providers. These pieces accommodate many requirements of 
electronic commerce including: 

! the distribution of permissions to use electronic 
information; 

! the persistence of the control information and sets of 
control information managing these permissions; 

! configurable control set information that can be 
selected by users for use with such information; 
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! data security and usage auditing of electronic 
information; and 

! a secure system for currency, compensation and 
debit management. 

For electronic commerce, a rights application, under the 
preferred embodiment of the present invention, can provide 
electronic enforcement of the business agreements between all 
participants. Since different groups of components can be put 
together for different applications, the present invention can 
provide electronic control information for a wide variety of 
different products and markets. This means the present 
invention can provide a "unified," efficient, secure, and 
cost-effective system for electronic commerce and data security. 
This allows VDE to serve as a single standard for electronic 
rights protection, data security, and electronic currency and 
banking. 

In a VDE, the separation between a rights application and 
its foundation permits the efficient selection of sets of control 
information that are appropriate for each of many different types 
of applications and uses. These control sets can reflect both 
rights of electronic community members, as well as obligations 
(such as providing a history of one's use of a product or paying 
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taxes on one's electronic purchases). VDE flexibility allows its 
users to electronically implement and enforce common social and 
commercial ethics and practices. By providing a unified control 
system, the present invention supports a vast range of possible 
transaction related interests and concerns of individuals, 
communities, businesses, and governments. Due to its open 
design, VDE allows (normally under securely controlled 
circumstances) applications using technology independently 
created by users to be "added" to the system and used in 
conjunction with the foundation of the invention. In sum, VDE 
provides a system that can fairly reflect and enforce agreements 
among parties. It is a broad ranging and systematic solution that 
answers the pressing need for a secure, cost-effective, and fair 
electronic environment. 

VDE Implementation 

The preferred embodiment of the present invention 
includes various tools that enable system designers to directly 
insert VDE capabilities into their products. These tools include 
an Application Programmer's Interface ("APF) and a Rights 
Permissioning and Management Language ("KPML"). The 
RPML provides comprehensive and detailed control over the use 
of the invention's features. VDE also includes certain user 
interface subsystems for satisfying the needs of content 
providers, distributors, and users. 



-19- 



WO 96/27155 



PCT/US96/02303 



Information distributed using VDE may take many forms. 
It may, for example, be "distributed* for use on an individual's 
own computer, that is the present invention can be used to 
provide security for locally stored data. Alternatively, VDE may 
be used with information that is dispersed by authors and/or 
publishers to one or more recipients. This information may take 
many forms including: movies, audio recordings, games, 
electronic catalog shopping, multimedia, training materials, 
E-mail and personal documents, object oriented libraries, 
software programming resources, and reference/record keeping 
information resources (such as business, medical, legal, scientific, 
governmental, and consumer databases). 

Electronic rights protection provided by the present 
invention will also provide an important foundation for trusted 
and efficient home and commercial banking, electronic credit 
processes, electronic purchasing, true or conditionally anonymous 
electronic cash, and EDI (Electronic Data Interchange). VDE 
provides important enhancements for improving data security in 
organizations by providing "smart" transaction management 
features that can be far more effective than key and password 
based "go/no go* technology. 

VDE normally employs an integration of cryptographic and 
other security technologies (e.g. encryption, digital signatures, 
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etc.), with other technologies including: component, distributed, 
and event driven operating system technology, and related 
co mmunic ations, object container, database, smart agent, smart 
card, and semiconductor design technologies. 

I. Overview 

A. VDE Solves Important Problems and Fills 
Critical Needs 

The world is moving towards an integration of electronic 

information appliances. This interconnection of appliances 

provides a foundation for much greater electronic interaction and 

the evolution of electronic commerce. A variety of capabilities are 

required to implement an electronic commerce environment. 

VDE is the first system that provides many of these capabilities 

and therefore solves fundamental problems related to electronic 

dissemination of information. 

Electronic Content 

VDE allows electronic arrangements to be created 
involving two or more parties. These agreements can themselves 
comprise a collection of agreements between participants in a 
commercial value chain and/or a data security chain model for 
handling, auditing, reporting, and payment. It can provide 
efficient, reusable, modifiable, and consistent means for secure 
electronic content: distribution, usage control, usage payment, 
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usage auditing, and usage reporting. Content may, for example, 
include: 

! financial information such as electronic currency and 
credit; 

! commercially distributed electronic information such 
as reference databases, movies, games, and 
advertising; and 

! electronic properties produced by persons and 
organizations, such as documents, e-mail, and 
proprietary database information. 



15 VDE enables an electronic commerce marketplace that supports 

differing, competitive business partnerships, agreements, and 
evolving overall business models. 
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The features of VDE allow it to function as the first trusted 
20 electronic information control environment that can conform to, 

and support, the bulk of conventional electronic commerce and 
data security requirements. In particular, VDE enables the 
participants in a business value chain model to create an 
electronic version of traditional business agreement terms and 
25 conditions and further enables these participants to shape and 
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evolve their electronic commerce models as they believe 
appropriate to their business requirements. 

VDE offers an architecture that avoids reflecting specific 
distribution biases, administrative and control perspectives, and 
content types. Instead, VDE provides a broad-spectrum, 
fundamentally configurable and portable, electronic transaction 
control, distributing, usage, auditing, reporting, and payment 
operating environment. VDE is not limited to being an 
application or application specific toolset that covers only a 
limited subset of electronic interaction activities and participants. 
Rather, VDE supports systems by which such applications can be 
created, modified, and/or reused. As a result, the present 
invention answers pressing, unsolved needs by offering a system 
that supports a standardized control environment which 
facilitates interoperability of electronic appliances, 
interoperability of content containers, and efficient creation of 
electronic commerce applications and models through the use of a 
programmable, secure electronic transactions management 
foundation and reusable and extensible executable components. 
VDE can support a single electronic "world" within which most 
forms of electronic transaction activities can be managed. 

To answer the developing needs of rights owners and 
content providers and to provide a system that can accommodate 
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the requirements and agreements of all parties that may be 
involved in electronic business models (creators, distributors, 
administrators, users, credit providers, etc.), VDE supplies an 
efficient, largely transparent, low cost and sufficiently secure 
system (supporting both hardware/ software and software only 
models). VDE provides the widely varying secure control and 
administration capabilities required for: 

1. Different types of electronic content, 

2. Differing electronic content delivery schemes, 

3. Differing electronic content usage schemes, 

4. Different content usage platforms, and 

5. Differing content marketing and model strategies. 

VDE may be combined with, or integrated into, many 
separate computers and/or other electronic appliances. These 
appliances typically include a secure subsystem that can enable 
control of content use such as displaying, encrypting, decrypting, 
printing, copying, saving, extracting, embedding, distributing, 
auditing usage, etc. The secure subsystem in the preferred 
embodiment comprises one or more "protected processing 
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environments", one or more secure databases, and secure 
"component assemblies" and other items and processes that need 
to be kept secured. VDE can, for example, securely control 
electronic currency, payments, and/or credit management 
(including electronic credit and/or currency receipt, 
disbursement, encumbering, and/or allocation) using such a 
"secure subsystem." 

VDE provides a secure, distributed electronic transaction 
management system for controlling the distribution and/or other 
usage of electronically provided and/or stored information. VDE 
controls auditing and reporting of electronic content and/or 
appliance usage. Users of VDE may include content creators who 
apply content usage, usage reporting, and/or usage payment 
related control information to electronic content and/or 
appliances for users such as end-user organizations, individuals, 
and content and/or appliance distributors. VDE also securely 
supports the payment of money owed (including money owed for 
content and/or appliance usage) by one or more parties to one or 
more other parties, in the form of electronic credit and/or 
currency. 

Electronic appliances under control of VDE represent VDE 
'nodes' that securely process and control; distributed electronic 
information and/or appliance usage, control information 
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formulation, and related transactions. VDE can securely manage 
the integration of control information provided by two or more 
parties. As a result, VDE can construct an electronic agreement 
between VDE participants that represent a "negotiation" 
between, the control requirements of, two or more parties and 
enacts terms and conditions of a resulting agreement. VDE 
ensures the rights of each party to an electronic agreement 
regarding a wide range of electronic activities related to 
electronic information and/or appliance usage. 

Through use of VDE's control system, traditional content 
providers and users can create electronic relationships that 
reflect traditional, non-electronic relationships. They can shape 
and modify commercial relationships to accommodate the 
evolving needs of, and agreements among, themselves. VDE does 
not require electronic content providers and users to modify their 
business practices and personal preferences to conform to a 
metering and control application program that supports limited, 
largely fixed functionality. Furthermore, VDE permits 
participants to develop business models not feasible with non- 
electronic commerce, for example, involving detailed reporting of 
content usage information, large numbers of distinct transactions 
at hitherto infeasibly low price points, "pass-along" control 
information that is enforced without involvement or advance 
knowledge of the participants, etc. 
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The present invention allows content providers and users 
to formulate their transaction environment to accommodate: 

(1) desired content models, content control models, and 
content usage information pathways, 

(2) a complete range of electronic media and distribution 
means, 

(3) a broad range of pricing, payment, and auditing 
strategies, 

(4) very flexible privacy and/or reporting models, 

(5) practical and effective security architectures, and 

(6) other administrative procedures that together with 
steps (1) through (5) can enable most "real world" 
electronic commerce and data security models, 
including models unique to the electronic world. 

VDE's transaction management capabilities can enforce: 
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(1) privacy rights of users related to information 
regarding their usage of electronic information 
and/or appliances, 

5 (2) societal policy such as laws that protect rights of 

content users or require the collection of taxes 
derived from electronic transaction revenue, and 

(3) the proprietary and/or other rights of parties related 
10 to ownership of, distribution of, and/or other 

commercial rights related to, electronic information. 

VDE can support "real" commerce in an electronic form, 
that is the progressive creation of commercial relationships that 

15 form, over time, a network of interrelated agreements 

representing a value chain business model. This is achieved in 
part by enabling content control information to develop through 
the interaction of (negotiation between) securely created and 
independently submitted sets of content and/or appliance control 

20 information. Different sets of content and/or appliance control 

information can be submitted by different parties in an electronic 
business value chain enabled by the present invention. These 
parties create control information sets through the use of their 
respective VDE installations. Independently, securely 

25 deliverable, component based control information allows efficient 
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interaction among control information sets supplied by different 
parties. 

VDE permits multiple, separate electronic arrangements to 
be formed between subsets of parties in a VDE supported 
electronic value chain model. These multiple agreements 
together comprise a VDE value chain "extended" agreement. 
VDE allows such constituent electronic agreements, and 
therefore overall VDE extended agreements, to evolve and 
reshape over time as additional VDE participants become 
involved in VDE content and/or appliance control information 
handling. VDE electronic agreements may also be extended as 
new control information is submitted by existing participants. 
With VDE, electronic commerce participants are free to structure 
and restructure their electronic commerce business activities and 
relationships. As a result, the present invention allows a 
competitive electronic commerce marketplace to develop since the 
use of VDE enables different, widely varying business models 
using the same or shared content. 

A significant facet of the present invention's ability to 
broadly support electronic commerce is its ability to securely 
manage independently delivered VDE component objects 
containing control information (normally in the form of VDE 
objects containing one or more methods, data, or load module 
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VDE components). This independently delivered control 
information can be integrated with senior and other pre-existing 
content control information to securely form derived control 
information using the negotiation mechanisms of the present 
invention. All requirements specified by this derived control 
information must be satisfied before VDE controlled content can 
be accessed or otherwise used. This means that, for example, all 
load modules and any mediating data which are listed by the 
derived control information as required must be available and 
securely perform their required function. In combination with 
other aspects of the present invention, securely, independently 
delivered control components allow electronic commerce 
participants to freely stipulate their business requirements and 
trade oflfs. As a result, much as with traditional, non-electronic 
commerce, the present invention allows electronic commerce 
(through a progressive stipulation of various control 
requirements by VDE participants) to evolve into forms of 
business that are the most efficient, competitive and useful. 

VDE provides capabilities that rationalize the support of 
electronic commerce and electronic transaction management. 
This rationalization stems from the reusability of control 
structures and user interfaces for a wide variety of transaction 
management related activities. As a result, content usage 
control, data security, information auditing, and electronic 
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financial activities, can be supported with tools that are reusable, 
convenient, consistent, and familiar. In addition, a rational 
approach — a transaction/distribution control standard — allows 
all participants in VDE the same foundation set of hardware 
control and security, authoring, administration, and 
management tools to support widely varying types of 
information, business market model, and/or personal objectives. 

Employing VDE as a general purpose electronic 
transaction/distribution control system allows users to maintain 
a single transaction management control arrangement on each of 
their computers, networks, communication nodes, and/or other 
electronic appliances. Such a general purpose system can serve 
the needs of many electronic transaction management 
applications without requiring distinct, different installations for 
different purposes. As a result, users of VDE can avoid the 
confusion and expense and other inefficiencies of different, 
limited purpose transaction control applications for each different 
content and/or business model. For example, VDE allows content 
creators to use the same VDE foundation control arrangement for 
both content authoring and for licensing content from other 
content creators for inclusion into their products or for other use. 
Clearinghouses, distributors, content creators, and other VDE 
users can all interact, both with the applications running on their 
VDE installations, and with each other, in an entirely consistent 
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manner, using and reusing (largely transparently) the same 
distributed tools, mechanisms, and consistent user interfaces, 
regardless of the type of VDE activity. 

VDE prevents many forms of unauthorized use of 
electronic information, by controlling and auditing (and other 
administration of use) electronically stored and/or disseminated 
information. This includes, for example, commercially 
distributed content, electronic currency, electronic credit, 
business transactions (such as EDI), confidential 
communications, and the like. VDE can further be used to enable 
commercially provided electronic content to be made available to 
users in user defined portions, rather than constraining the user 
to use portions of content that were "predetermined" by a content 
creator and/or other provider for billing purposes. 

VDE, for example, can employ: 

( 1) Secure metering means for budgeting and/or 
auditing electronic content and/or appliance usage; 

(2) Secure flexible means for enabling compensation 
and/or billing rates for content and/or appliance 
usage, including electronic credit and/or currency 
mechanisms for payment means; 
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Secure distributed database means for storing 
control and usage related information (and 
employing validated compartmentalization and 
tagging schemes); 

Secure electronic appliance control means; 

A distributed, secure, "virtual black box" comprised 
of nodes located at every user (including VDE 
content container creators, other content providers, 
client users, and recipients of secure VDE content 
usage information) site. The nodes of said virtual 
black box normally include a secure subsystem 
having at least one secure hardware element (a 
semiconductor element or other hardware module for 
securely executing VDE control processes), said 
secure subsystems being distributed at nodes along a 
pathway of information storage, distribution, 
payment, usage, and/or auditing. In some 
embodiments, the functions of said hardware 
element, for certain or all nodes, may be performed 
by software, for example, in host processing 
environments of electronic appliances; 

Encryption and decryption means; 
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(7) Secure communications means employing 
authentication, digital signaturing, and encrypted 
transmissions. The secure subsystems at said user 
nodes utilize a protocol that establishes and 
authenticates each node's and/or participant's 
identity, and establishes one or more secure 
host-to-host encryption keys for communications 
between the secure subsystems; and 

(8) Secure control means that can allow each VDE 
installation to perform VDE content authoring 
(placing content into VDE containers with associated 
control information), content distribution, and 
content usage; as well as clearinghouse and other 
administrative and analysis activities employing 
content usage information. 

VDE may be used to migrate most non-electronic, 
traditional information delivery models (including entertainment, 
reference materials, catalog shopping, etc.) into an adequately 
secure digital distribution and usage management and payment 
context. The distribution and financial pathways managed by a 
VDE arrangement may include: 

! content creators), 
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! distributors), 

! redistributed), 

! client administrators), 

! client user(s), 

! financial and/or other clearinghouse(s), 

! and/or government agencies. 

These distribution and financial pathways may also include: 

! advertisers, 

! market survey organizations, and/or 

! other parties interested in the user usage of 

information securely delivered and/or stored using 

VDE. 

Normally, participants in a VDE arrangement will employ the 
same secure VDE foundation. Alternate embodiments support 
VDE arrangements employing differing VDE foundations. Such 
alternate embodiments may employ procedures to ensure certain 
interoperability requirements are met. 

Secure VDE hardware (also known as SPUs for Secure 
Processing Units), or VDE installations that use software to 
substitute for, or complement, said hardware (provided by Host 
Processing Environments (HPEs)), operate in conjunction with 



-35- 



secure co mmuni cations, systems integration software, and 
distributed software control information and support structures, 
to achieve the electronic contract/rights protection environment 
of the present invention. Together, these VDE components 
comprise a secure, virtual, distributed content and/or appliance 
control, auditing (and other administration), reporting, and 
payment environment. In some embodiments and where 
commercially acceptable, certain VDE participants, such as 
clearinghouses that normally maintain sufficiently physically 
secure non-VDE processing environments, may be allowed to 
employ HPEs rather VDE hardware elements and interoperate, 
for example, with VDE end-users and content providers. VDE 
components together comprise a configurable, consistent, secure 
and "trusted" architecture for distributed, asynchronous control 
of electronic content and/or appliance usage. VDE supports a 
"universe wide" environment for electronic content delivery, 
broad dissemination, usage reporting, and usage related payment 
activities. 

VDE provides generalized configurability. This results, in 
part, from decomposition of generalized requirements for 
supporting electronic commerce and data security into a broad 
range of constituent "atomic" and higher level components (such 
as load modules, data elements, and methods) that may be 
variously aggregated together to form control methods for 
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electronic commerce applications, commercial electronic 
agreements, and data security arrangements. VDE provides a 
secure operating environment employing VDE foundation 
elements along with secure independently deliverable VDE 
components that enable electronic commerce models and 
relationships to develop. VDE specifically supports the unfolding 
of distribution models in which content providers, over time, can 
expressly agree to, or allow, subsequent content providers and/or 
users to participate in shaping the control information for, and 
consequences of, use of electronic content and/or appliances. A 
very broad range of the functional attributes important for 
supporting simple to very complex electronic commerce and data 
security activities are supported by capabilities of the present 
invention. As a result, VDE supports most types of electronic 
information and/or appliance: usage control (including 
distribution), security, usage auditing, reporting, other 
administration, and payment arrangements. 

VDE, in its preferred embodiment, employs object software 
technology and uses object technology to form "containers" for 
delivery of information that is (at least in part) encrypted or 
otherwise secured. These containers may contain electronic 
content products or other electronic information and some or all 
of their associated permissions (control) information. These 
container objects may be distributed along pathways involving 
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content providers and/or content users. They may be securely 
moved among nodes of a Virtual Distribution Environment 
(VDE) arrangement, which nodes operate VDE foundation 
software and execute control methods to enact electronic 
information usage control and/or administration models. The 
containers delivered through use of the preferred embodiment of 
the present invention may be employed both for distributing VDE 
control instructions (information) and/or to encapsulate and 
electronically distribute content that has been at least partially 
secured. 

Content providers who employ the present invention may 
include, for example, software application and game publishers, 
database publishers, cable, television, and radio broadcasters, 
electronic shopping vendors, and distributors of information in 
electronic document, book, periodical, e-mail and/or other forms. 
Corporations, government agencies, and/or individual "end-users" 
who act as storers of, and/or distributors of, electronic 
information, may also be VDE content providers (in a restricted 
model, a user provides content only to himself and employs VDE 
to secure his own confidential information against unauthorized 
use by other parties). Electronic information may include 
proprietary and/or confidential information for personal or 
internal organization use, as well as information, such as 
software applications, documents, entertainment materials, 
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and/or reference information, which may be provided to other 
parties. Distribution may be by, for example, physical media 
delivery, broadcast and/or telecommunication means, and in the 
form of "static* files and/or streams of data. VDE may also be 
used, for example, for multi-site "real-time" interaction such as 
teleconferencing, interactive games, or on-line bulletin boards, 
where restrictions on, and/or auditing of, the use of all or portions 
of communicated information is enforced. 

VDE provides important mechanisms for both enforcing 
commercial agreements and enabling the protection of privacy 
rights. VDE can securely deliver information from one party to 
another concerning the use of commercially distributed electronic 
content. Even if parties are separated by several "steps" in a 
chain (pathway) of handling for such content usage information, 
such information is protected by VDE through encryption and/or 
other secure processing. Because of that protection, the accuracy 
of such information is guaranteed by VDE, and the information 
can be trusted by all parties to whom it is delivered. 
Furthermore, VDE guarantees that all parties can trust that 
such information cannot be received by anyone other than the 
intended, authorized, party(ies) because it is encrypted such that 
only an authorized party, or her agents, can decrypt it. Such 
information may also be derived through a secure VDE process at 
a previous pathway-of-handling location to produce secure VDE 
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reporting information that is then communicated securely to its 
intended recipient's VDE secure subsystem. Because VDE can 
deliver such information securely, parties to an electronic 
agreement need not trust the accuracy of commercial usage 
and/or other information delivered through means other than 
those under control of VDE. 

VDE participants in a commercial value chain can be 
"commercially" confident (that is, sufficiently confident for 
commercial purposes) that the direct (constituent) and/or 
"extended" electronic agreements they entered into through the 
use of VDE can be enforced reliably. These agreements may have 
both "dynamic" transaction management related aspects, such as 
content usage control information enforced through budgeting, 
metering, and/or reporting of electronic information and/or 
appliance use, and/or they may include "static" electronic 
assertions, such as an end-user using the system to assert his or 
her agreement to pay for services, not to pass to unauthorized 
parties electronic information derived from usage of content or 
systems, and/or agreeing to observe copyright laws. Not only can 
electronically reported transaction related information be trusted 
under the present invention, but payment may be automated by 
the passing of payment tokens through a pathway of payment 
(which may or may not be the same as a pathway for reporting). 
Such payment can be contained within a VDE container created 
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automatically by a VDE installation in response to control 
information (located, in the preferred embodiment, in one or more 
permissions records) stipulating the "withdrawal" of credit or 
electronic currency (such as tokens) from an electronic account 
(for example, an account securely maintained by a user's VDE 
installation secure subsystem) based upon usage of VDE 
controlled electronic content and/or appliances (such as 
governments, financial credit providers, and users). 

VDE allows the needs of electronic commerce participants 
to be served and it can bind such participants together in a 
universe wide, trusted commercial network that can be secure 
enough to support veiy large amounts of commerce. VDE's 
security and metering secure subsystem core will be present at 
all physical locations where VDE related content is (a) assigned 
usage related control information (rules and mediating data), 
and/or (b) used. This core can perform security and auditing 
functions (including metering) that operate within a "virtual 
black box," a collection of distributed, very secure VDE related 
hardware instances that are interconnected by secured 
information exchange (for example, telecommunication) processes 
and distributed database means. VDE further includes highly 
configurable transaction operating system technology, one or 
more associated libraries of load modules along with affiliated 
data, VDE related administration, data preparation, and analysis 
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applications, as well as system software designed to enable VDE 
integration into host environments and applications. VDE's 
usage control information, for example, provide for property 
content and/or appliance related: usage authorization, usage 
auditing (which may include audit reduction), usage billing, 
usage payment, privacy filtering, reporting, and security related 
communication and encryption techniques. 

VDE extensively employs methods in the form of software 
objects to augment configurability, portability, and security of the 
VDE environment. It also employs a software object architecture 
for VDE content containers that carries protected content and 
may also carry both freely available information (e.g, summary, 
table of contents) and secured content control information which 
ensures the performance of control information. Content control 
information governs content usage according to criteria set by 
holders of rights to an object's contents and/or according to 
parties who otherwise have rights associated with distributing 
such content (such as governments, financial credit providers, 
and users). 

In part, security is enhanced by object methods employed 
by the present invention because the encryption schemes used to 
protect an object can efficiently be further used to protect the 
associated content control information (software control 
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information and relevant data) from modification. Said object 
techniques also enhance portability between various computer 
and/or other appliance environments because electronic 
information in the form of content can be inserted along with (for 
example, in the same object container as) content control 
information (for said content) to produce a "published" object. As 
a result, various portions of said control information may be 
specifically adapted for different environments, such as for 
diverse computer platforms and operating systems, and said 
various portions may all be carried by a VDE container. 

An objective of VDE is supporting a 
transaction/distribution control standard. Development of such a 
standard has many obstacles, given the security requirements 
and related hardware and communications issues, widely 
differing environments, information types, types of information 
usage, business and/or data security goals, varieties of 
participants, and properties of delivered information. A 
significant feature of VDE accommodates the many, varying 
distribution and other transaction variables by, in part, 
decomposing electronic commerce and data security functions 
into generalized capability modules executable within a secure 
hardware SPU and/or corresponding software subsystem and 
further allowing extensive flexibility in assembling, modifying, 
and/or replacing, such modules (e.g. load modules and/or 
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methods) in applications run on a VDE installation foundation. 
This configurability and reconfigurability allows electronic 
commerce and data security participants to reflect their priorities 
and requirements through a process of iteratively shaping an 
5 evolving extended electronic agreement (electronic control 

model). This shaping can occur as content control information 
passes from one VDE participant to another and to the extent 
allowed by "in place" content control information. This process 
allows users of VDE to recast existing control information and/or 
10 add new control information as necessary (including the 

elimination of no longer required elements). 

VDE supports trusted (sufficiently secure) electronic 
information distribution and usage control models for both 

15 commercial electronic content distribution and data security 

applications. It can be configured to meet the diverse 
requirements of a network of interrelated participants that may 
include content creators, content distributors, client 
administrators, end users, and/or clearinghouses and/or other 

20 content usage information users. These parties may constitute a 

network of participants involved in simple to complex electronic 
content dissemination, usage control, usage reporting, and/or 
usage payment. Disseminated content may include both 
originally provided and VDE generated information (such as 

25 content usage information) and content control information may 
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persist through both chains (one or more pathways) of content 
and content control information handling, as well as the direct 
usage of content. The configurability provided by the present 
invention is particularly critical for supporting electronic 
commerce, that is enabling businesses to create relationships and 
evolve strategies that offer competitive value. Electronic 
commerce tools that are not inherently configurable and 
interoperable will ultimately fail to produce products (and 
services) that meet both basic requirements and evolving needs of 
most commerce applications. 

VDE's fundamental configurability will allow a broad 
range of competitive electronic commerce business models to 
flourish. It allows business models to be shaped to maximize 
revenues sources, end-user product value, and operating 
efficiencies. VDE can be employed to support multiple, differing 
models, take advantage of new revenue opportunities, and 
deliver product configurations most desired by users. Electronic 
commerce technologies that do not, as the present invention does: 

! support a broad range of possible, complementary 
revenue activities, 

! offer a flexible array of content usage features most 
desired by customers, and 

! exploit opportunities for operating efficiencies, 
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will result in products that are often intrinsically more costly and 
less appealing and therefore less competitive in the marketplace. 

Some of the key factors contributing to the configurability 
5 intrinsic to the present invention include : 

(a) integration into the fundamental control 
environment of a broad range of electronic 
appliances through portable API and programming 
10 language tools that efficiently support merging of 

control and auditing capabilities in nearly any 
electronic appliance environment while maintaining 
overall system security; 



15 (b) modular data structures; 



(c) generic content model; 



(d) general modularity and independence of foundation 
20 architectural components; 

(e) modular security structures; 

(f) variable length and multiple branching chains of 
25 control; and 
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(g) independent, modular control structures in the form 
of executable load modules that can be maintained in 
one or more libraries, and assembled into control 
methods and models, and where such model control 
schemes can "evolve* as control information passes 
through the VDE installations of participants of a 
pathway of VDE content control information 
handling. 

Because of the breadth of issues resolved by the present 
invention, it can provide the emerging "electronic highway" with 
a single transaction/distribution control system that can, for a 
very broad range of commercial and data security models, ensure 
against unauthorized use of confidential and/or proprietary 
information and commercial electronic transactions. VDE's 
electronic transaction management mechanisms can enforce the 
electronic rights and agreements of all parties participating in 
widely varying business and data security models, and this can 
be efficiently achieved through a single VDE implementation 
within each VDE participant's electronic appliance. VDE 
supports widely varying business and/or data security models 
that can involve a broad range of participants at various "levels" 
of VDE content and/or content control information pathways of 
handling. DifFerent content control and/or auditing models and 
agreements may be available on the same VDE installation. 
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These models and agreements may control content in 
relationship to, for example, VDE installations and/or users in 
general; certain specific users, installations, classes and/or other 
groupings of installations and/or users; as well as to electronic 
content generally on a given installation, to specific properties, 
property portions, classes and/or other groupings of content. 

Distribution using VDE may package both the electronic 
content and control information into the same VDE container, 
and/or may involve the delivery to an end-user site of different 
pieces of the same VDE managed property from plural separate 
remote locations and/or in plural separate VDE content 
containers and/or employing plural different delivery means. 
Content control information may be partially or fully delivered 
separately from its associated content to a user VDE installation 
in one or more VDE administrative objects. Portions of said 
control information may be delivered from one or more sources. 
Control information may also be available for use by access from 
a user's VDE installation secure sub-system to one or more 
remote VDE secure sub-systems and/or VDE compatible, certified 
secure remote locations. VDE control processes such as 
metering, budgeting, decrypting and/or fingerprinting, may as 
relates to a certain user content usage activity, be performed in a 
user's local VDE installation secure subsystem, or said processes 
may be divided amongst plural secure subsystems which may be 
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located in the same user VDE installations and/or in a network 
server and in the user installation. For example, a local VDE 
installation may perform decryption and save any, or all of, usage 
metering information related to content and/or electronic 
appliance usage at such user installation could be performed at 
the server employing secure (e.g., encrypted) communications 
between said secure subsystems. Said server location may also 
be used for near real time, frequent, or more periodic secure 
receipt of content usage information from said user installation, 
with, for example, metered information being maintained only 
temporarily at a local user installation. 

Delivery means for VDE managed content may include 
electronic data storage means such as optical disks for delivering 
one portion of said information and broadcasting and/or 
telecommunicating means for other portions of said information. 
Electronic data storage means may include magnetic media, 
optical media, combined magneto-optical systems, flash RAM 
memory, bubble memory, and/or other memory storage means 
such as huge capacity optical storage systems employing 
holographic, frequency, and/or polarity data storage techniques. 
Data storage means may also employ layered disc techniques, 
such as the use of generally transparent and/or translucent 
materials that pass light through layers of data carrying discs 
which themselves are physically packaged together as one 
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thicker disc. Data carrying locations on such discs may be, at 
least in part, opaque. 

VDE supports a general purpose foundation for secure 
transaction management, including usage control, auditing, 
reporting, and/or payment. This general purpose foundation is 
called "VDE Functions" ("VDEFs *). VDE also supports a 
collection of "atomic" application elements (e.g., load modules) 
that can be selectively aggregated together to form various VDEF 
capabilities called control methods and which serve as VDEF 
applications and operating system functions. When a host 
operating environment of an electronic appliance includes VDEF 
capabilities, it is called a "Eights Operating System" (ROS). 
VDEF load modules, associated data, and methods form a body of 
information that for the purposes of the present invention are 
called "control information." VDEF control information may be 
specifically associated with one or more pieces of electronic 
content and/or it may be employed as a general component of the 
operating system capabilities of a VDE installation. 

VDEF transaction control elements reflect and enact 
content specific and/or more generalized administrative (for 
example, general operating system) control information. VDEF 
capabilities which can generally take the form of applications 
(application models) that have more or less configurability which 



-50- 



WO 96/27155 



PCT7US96/02303 



can be shaped by VDE participants, through the use, for 
example, of VDE templates, to employ specific capabilities, along, 
for example, with capability parameter data to reflect the 
elements of one or more express electronic agreements between 
VDE participants in regards to the use of electronic content such 
as commercially distributed products. These control capabilities 
manage the vise of, and/or auditing of use of, electronic content, 
as well as reporting information based upon content use, and any 
payment for said use. VDEF capabilities may "evolve* to reflect 
the requirements of one or more successive parties who receive or 
otherwise contribute to a given set of control information. 
Frequently, for a VDE application for a given content model (such 
as distribution of entertainment on CD-ROM, content delivery 
from an Internet repository, or electronic catalog shopping and 
advertising, or some combination of the above) participants 
would be able to securely select from amongst available, 
alternative control methods and apply related parameter data, 
wherein such selection of control method and/or submission of 
data would constitute their "contribution" of control information. 
Alternatively, or in addition, certain control methods that have 
been expressly certified as securely interoperable and compatible 
with said application may be independently submitted by a 
participant as part of such a contribution. In the most general 
example, a generally certified load module (certified for a given 
VDE arrangement and/or content class) may be used with many 
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or any VDE application that operates in nodes of said 
arrangement. These parties, to the extent they are allowed, can 
independently and securely add, delete, and/or otherwise modify 
the specification of load modules and methods, as well as add, 
delete or otherwise modify related information. 

Normally the party who creates a VDE content container 
defines the general nature of the VDEF capabilities that will 
and/or may apply to certain electronic information. A VDE 
content container is an object that contains both content ( for 
example, commercially distributed electronic information 
products such as computer software programs, movies, electronic 
publications or reference materials, etc.) and certain control 
information related to the use of the object's content. A creating 
party may make a VDE container available to other parties. 
Control information delivered by, and/or otherwise available for 
use with, VDE content containers comprise (for commercial 
content distribution purposes) VDEF control capabilities (and 
any associated parameter data) for electronic content. These 
capabilities may constitute one or more "proposed* electronic 
agreements (and/or agreement functions available for selection 
and/or use with parameter data) that manage the use and/or the 
consequences of use of such content and which can enact the 
terms and conditions of agreements involving multiple parties 
and their various rights and obligations. 
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A VDE electronic agreement may be explicit, through a 
user interface acceptance by one or more parties, for example by 
a "junior" party who has received control information from a 
"senior* party, or it may be a process amongst equal parties who 
individually assert their agreement. Agreement may also result 
from an automated electronic process during which terms and 
conditions are "evaluated" by certain VDE participant control 
information that assesses whether certain other electronic terms 
and conditions attached to content and/or submitted by another 
party are acceptable (do not violate acceptable control 
information criteria). Such an evaluation process may be quite 
simple, for example a comparison to ensure compatibility 
between a portion of, or all senior, control terms and conditions in 
a table of terms and conditions and the submitted control 
information of a subsequent participant in a pathway of content 
control information handling, or it may be a more elaborate 
process that evaluates the potential outcome of, and/or 
implements a negotiation process between, two or more sets of 
control information submitted by two or more parties. VDE also 
accommodates a semi-automated process during which one or 
more VDE participants directly, through user interface means, 
resolve "disagreements* between control information sets by 
accepting and/or proposing certain control information that may 
be acceptable to control information representing one or more 
other parties interests and/or responds to certain user interface 
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queries for selection of certain alternative choices and/or for 
certain parameter information, the responses being adopted if 
acceptable to applicable senior control information. 

When another party (other than the first applier of rules), 
perhaps through a negotiation process, accepts, and/or adds to 
and/or otherwise modifies, w in place" content control information, 
a VDE agreement between two or more parties related to the use 
of such electronic content may be created (so long as any 
modifications are consistent with senior control information). 
Acceptance of terms and conditions related to certain electronic 
content may be direct and express, or it may be implicit as a 
result of use of content (depending, for example, on legal 
requirements, previous exposure to such terms and conditions, 
and requirements of in place control information). 

VDEF capabilities may be employed, and a VDE 
agreement may be entered into, by a plurality of parties without 
the VDEF capabilities being directly associated with the 
controlling of certain, specific electronic information. For 
example, certain one or more VDEF capabilities may be present 
at a VDE installation, and certain VDE agreements may have 
been entered into during the registration process for a content 
distribution application, to be used by such installation for 
securely controlling VDE content usage, auditing, reporting 
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and/or payment. Similarly, a specific VDE participant may enter 
into a VDE user agreement with a VDE content or electronic 
appliance provider when the user and/or her appliance register 
with such provider as a VDE installation and/or user. In such 
events, VDEF in place control information available to the user 
VDE installation may require that certain VDEF methods are 
employed, for example in a certain sequence, in order to be able 
to use all and/or certain classes, of electronic content and/or VDE 
applications. 

VDE ensures that certain prerequisites necessary for a 
given transaction to occur are met. This includes the secure 
execution of any required load modules and the availability of 
any required, associated data. For example, required load 
modules and data (e.g. in the form of a method) might specify 
that sufficient credit from an authorized source must be 
confirmed as available. It might further require certain one or 
more load modules execute as processes at an appropriate time to 
ensure that such credit will be used in order to pay for user use of 
the content. A certain content provider might, for example, 
require metering the number of copies made for distribution to 
employees of a given software program (a portion of the program 
might be maintained in encrypted form and require the presence 
of a VDE installation to run). This would require the execution of 
a metering method for copying of the property each time a copy 
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was made for another employee. This same provider might also 
charge fees based on the total number of different properties 
licensed from them by the user and a metering history of their 
licensing of properties might be required to maintain this 
information. 

VDE provides organization, community, and/or universe 
wide secure environments whose integrity is assured by 
processes securely controlled in VDE participant user 
installations (nodes). VDE installations, in the preferred 
embodiment, may include both software and tamper resistant 
hardware semiconductor elements. Such a semiconductor 
arrangement comprises, at least in part, special purpose circuitry 
that has been designed to protect against tampering with, or 
unauthorized observation of, the information and functions used 
in performing the VDE's control functions. The special purpose 
secure circuitry provided by the present invention includes at 
least one of: a dedicated semiconductor arrangement known as a 
Secure Processing Unit (SPU) and/or a standard microprocessor, 
microcontroller, and/or other processing logic that accommodates 
the requirements of the present invention and functions as an 
SPU. VDE's secure hardware may be found incorporated into, for 
example, a fax/modem chip or chip pack, I/O controller, video 
display controller, and/or other available digital processing 
arrangements. It is anticipated that portions of the present 
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invention's VDE secure hardware capabilities may ultimately be 
standard design elements of central processing units (CPUs) for 
computers and various other electronic devices. 

5 Designing VDE capabilities into one or more standard 

microprocessor, microcontroller and/or other digital processing 
components may materially reduce VDE related hardware costs 
by employing the same hardware resources for both the 
transaction management uses contemplated by the present 

10 invention and for other, host electronic appliance functions. This 

means that a VDE SPU can employ (share) circuitry elements of 
a "standard" CPU. For example, if a "standard" processor can 
operate in protected mode and can execute VDE related 
instructions as a protected activity, then such an embodiment 

15 may provide sufficient hardware security for a variety of 

applications and the expense of a special purpose processor might 
be avoided. Under one preferred embodiment of the present 
invention, certain memory (e.g., RAM, ROM, NVRAM) is 
maintained during VDE related instruction processing in a 

20 protected mode (for example, as supported by protected mode 

microprocessors). This memory is located in the same package as 
the processing logic (e.g. processor). Desirably, the packaging 
and memory of such a processor would be designed using security 
techniques that enhance its resistance to tampering. 

25 



-57- 



The degree of overall security of the VDE system is 
primarily dependent on the degree of tamper resistance and 
concealment of VDE control process execution and related data 
storage activities. Employing special purpose semiconductor 
packaging techniques can significantly contribute to the degree of 
security. Concealment and tamper-resistance in semiconductor 
memory (e.g., RAM, ROM, NVRAM) can be achieved, in part, by 
employing such memory within an SPU package, by encrypting 
data before it is sent to external memory (such as an external 
RAM package) and decrypting encrypted data within the 
CPU/RAM package before it is executed. This process is used for 
important VDE related data when such data is stored on 
unprotected media, for example, standard host storage, such as 
random access memory, mass storage, etc. In that event, a VDE 
SPU would encrypt data that results from a secure VDE 
execution before such data was stored in external memory. 

Summary of Some Important Features Provided by VDE in 
Accordance With the Present Invention 

VDE employs a variety of capabilities that serve as a 

foundation for a general purpose, sufficiently secure distributed 

electronic commerce solution. VDE enables an electronic 

commerce marketplace that supports divergent, competitive 

business partnerships, agreements, and evolving overall business 

models. For example, VDE includes features that: 
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"sufficiently" impede unauthorized and/or 
uncompensated use of electronic information and/or 
appliances through the use of secure communication, 
storage, and transaction management technologies. 
VDE supports a model wide, distributed security 
implementation which creates a single secure 
"virtual" transaction processing and information 
storage environment. VDE enables distributed VDE 
installations to securely store and co mmuni cate 
information and remotely control the execution 
processes and the character of use of electronic 
information at other VDE installations and in a wide 
variety of ways; 

support low-cost, efficient, and effective security 
architectures for transaction control, auditing, 
reporting, and related communications and 
information storage. VDE may employ tagging 
related security techniques, the time-ageing of 
encryption keys, the compartmentalization of both 
stored control information (including deferentially 
tagging such stored information to ensure against 
substitution and tampering) and distributed content 
(to, for many content applications, employ one or 
more content encryption keys that are unique to the 
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specific VDE installation and/or user), private key 
techniques such as triple DES to encrypt content, 
public key techniques such as RSA to protect 
communications and to provide the benefits of digital 
signature and authentication to securely bind 
together the nodes of a VDE arrangement, secure 
processing of important transaction management 
executable code, and a combining of a small amount 
of highly secure, hardware protected storage space 
with a much larger "exposed" mass media storage 
space storing secured (normally encrypted and 
tagged) control and audit information. VDE employs 
special purpose hardware distributed throughout 
some or all locations of a VDE implementation: a) 
said hardware controlling important elements of: 
content preparation (such as causing such content to 
be placed in a VDE content container and 
associating content control information with said 
content), content and/or electronic appliance usage 
auditing, content usage analysis, as well as content 
usage control; and b) said hardware having been 
designed to securely handle processing load module 
control activities, wherein said control processing 
activities may involve a sequence of required control 
factors; 
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support dynamic user selection of information 
subsets of a VDE electronic information product 
(VDE controlled content). This contrasts with the 
constraints of having to use a few high level 
individual, pre-defined content provider information 
increments such as being required to select a whole 
information product or product section in order to 
acquire or otherwise use a portion of such product or 
section. VDE supports metering and usage control 
over a variety of increments (including a atomic" 
increments, and combinations of different increment 
types) that are selected ad hoc by a user and 
represent a collection of pre-identified one or more 
increments (such as one or more blocks of a 
preidentified nature, e.g., bytes, images, logically 
related blocks) that form a generally arbitrary, but 
logical to a user, content "deliverable." VDE control 
information (including budgeting, pricing and 
metering) can be configured so that it can specifically 
apply, as appropriate, to ad hoc selection of different, 
unanticipated variable user selected aggregations of 
information increments and pricing levels can be, at 
least in part, based on quantities and/or nature of 
mixed increment selections (for example, a certain 
quantity of certain text could mean associated 
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images might be discounted by 15%; a greater 
quantity of text in the "mixed" increment selection 
might mean the images are discounted 20%). Such 
user selected aggregated information increments can 
reflect the actual requirements of a user for 
information and is more flexible than being limited 
to a single, or a few, high level, (e.g. product, 
document, database record) predetermined 
increments. Such high level increments may include 
quantities of information not desired by the user and 
as a result be more costly than the subset of 
information needed by the user if such a subset was 
available. In sum, the present invention allows 
information contained in electronic information 
products to be supplied according to user 
specification. Tailoring to user specification allows 
the present invention to provide the greatest value to 
users, which in turn will generate the greatest 
amount of electronic commerce activity. The user, 
for example, would be able to define an aggregation 
of content derived from various portions of an 
available content product, but which, as a 
deliverable for use by the user, is an entirely unique 
aggregated increment. The user may, for example, 
select certain numbers of bytes of information from 
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various portions of an information product, such as a 
reference work, and copy them to disc in 
unencrypted form and be billed based on total 
number of bytes plus a surcharge on the number of 
5 "articles" that provided the bytes. A content 

provider might reasonably charge less for such a 
user defined information increment since the user 
does not require all of the content from all of the 
articles that contained desired information. This 

10 process of defining a user desired information 

increment may involve artificial intelligence 
database search tools that contribute to the location 
of the most relevant portions of information from an 
information product and cause the automatic display 

15 to the user of information describing search criteria 

hits for user selection or the automatic extraction 
and delivery of such portions to the user. VDE 
further supports a wide variety of predefined 
increment types including: 

20 ! bytes, 

! images, 

! content over time for audio or video, or any 
other increment that can be identified by content 
provider data mapping efforts, such as: 
25 ! sentences, 
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! paragraphs, 

! articles, 

! database records, and 

! byte offsets representing increments of 
5 logically related information. 

VDE supports as many simultaneous predefined increment types 
as may be practical for a given type of content and business 
model. 

10 ! securely store at a user's site potentially highly 

detailed information reflective of a user's usage of a 
variety of different content segment types and 
employing both inexpensive "exposed* host mass 
storage for maintaining detailed information in the 
15 form of encrypted data and maintaining summary 

information for security testing in highly secure 
special purpose VDE installation nonvolatile 
memory (if available). 

support trusted chain of handling capabilities for 
pathways of distributed electronic information 
and/or for content usage related information. Such 
chains may extend, for example, from a content 
creator, to a distributor, a redistributor, a client 
user, and then may provide a pathway for securely 



20 ! 



25 
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reporting the same and/or differing usage 
information to one or more auditors, such as to one 
or more independent clearinghouses and then back 
to the content providers, including content creators. 
5 The same and/or different pathways employed for 

certain content handling, and related content control 
information and reporting information handling, 
may also be employed as one or more pathways for 
electronic payment handling (payment is 

10 characterized in the present invention as 

administrative content) for electronic content and/or 
appliance usage. These pathways are used for 
conveyance of all or portions of content, and/or 
content related control information. Content 

15 creators and other providers can specify the 

pathways that, partially or fully, must be used to 
disseminate commercially distributed property 
content, content control information, payment 
administrative content, and/or associated usage 

20 reporting information. Control information specified 

by content providers may also specify which specific 
parties must or may (including, for example, a group 
of eligible parties from which a selection may be 
made) handle conveyed information. It may also 

25 specify what transmission means (for example 
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telecommunication carriers or media types) and 
transmission hubs must or may be used. 

support flexible auditing mechanisms, such as 
employing "bitmap meters," that achieve a high 
degree of efficiency of operation and throughput and 
allow, in a practical manner, the retention and ready 
recall of information related to previous usage 
activities and related patterns. This flexibility is 
adaptable to a wide variety of billing and security 
control strategies such as: 
P upgrade pricing (e.g. suite purchases), 
P pricing discounts (including quantity 
discounts), 

P billing related time duration variables such as 
discounting new purchases based on the 
timing of past purchases, and 

P security budgets based on quantity of 

different, logically related units of electronic 
information used over an interval of time. 

Use of bitmap meters (including "regular" and "wide* 
bitmap meters) to record usage and/or purchase of 
information, in conjunction with other elements of 
the preferred embodiment of the present invention, 
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uniquely supports efficient maintenance of usage 
history for: (a) rental, (b) flat fee licensing or 
purchase, (c) licensing or purchase discounts based 
upon historical usage variables, and (d) reporting to 
users in a manner enabling users to determine 
whether a certain item was acquired, or acquired 
within a certain time period (without requiring the 
use of conventional database mechanisms, which are 
highly inefficient for these applications). Bitmap 
meter methods record activities associated with 
electronic appliances, properties, objects, or portions 
thereof, and/or administrative activities that are 
independent of specific properties, objects, etc., 
performed by a user and/or electronic appliance such 
that a content and/or appliance provider and/or 
controller of an administrative activity can 
determine whether a certain activity has occurred at 
some point, or during a certain period, in the past 
(for example, certain use of a commercial electronic 
content product and/or appliance). Such 
determinations can then be used as part of pricing 
and/or control strategies of a content and/or 
appliance provider, and/or controller of an 
administrative activity. For example, the content 
provider may choose to charge only once for access to 
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a portion of a property, regardless of the number of 
times that portion of the property is accessed by a 
user. 

support "launchable* content, that is content that 
can be provided by a content provider to an end-user, 
who can then copy or pass along the content to other 
end-user parties without requiring the direct 
participation of a content provider to register and/or 
otherwise initialize the content for use. This content 
goes "out of (the traditional distribution) channel* in 
the form of a "traveling object.* Traveling objects are 
containers that securely carry at least some 
permissions information and/or methods that are 
required for their use (such methods need not be 
carried by traveling objects if the required methods 
will be available at, or directly available to, a 
destination VDE installation). Certain travelling 
objects may be used at some or all VDE installations 
of a given VDE arrangement since they can make 
available the content control information necessary 
for content use without requiring the involvement of 
a commercial VDE value chain participant or data 
security administrator (e.g. a control officer or 
network administrator). As long as traveling object 
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control information requirements are available at 
the user VDE installation secure subsystem (such as 
the presence of a sufficient quantity of financial 
credit from an authorized credit provider), at least 
some travelling object content may be used by a 
receiving party without the need to establish a 
connection with a remote VDE authority (until, for 
example, budgets are exhausted or a time content 
usage reporting interval has occurred). Traveling 
objects can travel "out-of-channel," allowing, for 
example, a user to give a copy of a traveling object 
whose content is a software program, a movie or a 
game, to a neighbor, the neighbor being able to use 
the traveling object if appropriate credit (e.g. an 
electronic clearinghouse account from a 
clearinghouse such as VISA or AT&T) is available. 
Similarly, electronic information that is generally 
available on an Internet, or a similar network, 
repository might be provided in the form of a 
traveling object that can be downloaded and 
subsequently copied by the initial downloader and 
then passed along to other parties who may pass the 
object on to additional parties. 
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provide very flexible and extensible user 
identification according to individuals, installations, 
by groups such as classes, and by function and 
hierarchical identification employing a hierarchy of 
levels of client identification (for example, client 
organization ID, client department ID, client 
network ID, client project ID, and client employee 
ID, or any appropriate subset of the above). 

provide a general purpose, secure, component based 
content control and distribution system that 
functions as a foundation transaction operating 
system environment that employs executable code 
pieces crafted for transaction control and auditing. 
These code pieces can be reused to optimize 
efficiency in creation and operation of trusted, 
distributed transaction management arrangements. 
VDE supports providing such executable code in the 
form of "atomic" load modules and associated data. 
Many such load modules are inherently configurable, 
aggregatable, portable, and extensible and 
singularly, or in combination (along with associated 
data), run as control methods under the VDE 
transaction operating environment. VDE can satisfy 
the requirements of widely differing electronic 
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commerce and data security applications by, in part, 
employing this general purpose transaction 
management foundation to securely process VDE 
transaction related control methods. Control 
methods are created primarily through the use of 
one or more of said executable, reusable load module 
code pieces (normally in the form of executable object 
components) and associated data. The component 
nature of control methods allows the present 
invention to efficiently operate as a highly 
configurable content control system. Under the 
present invention, content control models can be 
iteratively and asynchronously shaped, and 
otherwise updated to accommodate the needs of VDE 
participants to the extent that such shaping and 
otherwise updating conforms to constraints applied 
by a VDE application, if any (e.g., whether new 
component assemblies are accepted and, if so, what 
certification requirements exist for such component 
assemblies or whether any or certain participants 
may shape any or certain control information by 
selection amongst optional control information 
(permissions record) control methods. This iterative 
(or concurrent) multiple participant process occurs 
as a result of the submission and use of secure, 
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control information components (executable code 
such as load modules and/or methods, and/or 
associated data). These components may be 
contributed independently by secure communication 
between each control information influencing VDE 
participant's VDE installation and may require 
certification for use with a given application, where 
such certification was provided by a certification 
service manager for the VDE arrangement who 
ensures secure interoperability and/or reliability 
(e.g., bug control resulting from interaction) between 
appliances and submitted control methods. The 
transaction management control functions of a VDE 
electronic appliance transaction operating 
environment interact with non-secure transaction 
management operating system functions to properly 
direct transaction processes and data related to 
electronic information security, usage control, 
auditing, and usage reporting. VDE provides the 
capability to manages resources related to secure 
VDE content and/or appliance control information 
execution and data storage. 

facilitate creation of application and/or system 
functionality under VDE and to facilitate integration 
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into electronic appliance environments of load 
modules and methods created under the present 
invention. To achieve this, VDE employs an 
Application Programmer's Interface (API) and/or a 
transaction operating system (such as a ROS) 
programming language with incorporated functions, 
both of which support the use of capabilities and can 
be used to efficiently and tightly integrate VDE 
functionality into commercial and user applications. 

support user interaction through: (a) "Pop-Up n 
applications which, for example, provide messages to 
users and enable users to take specific actions such 
as approving a transaction, (b) stand-alone VDE 
applications that provide administrative 
environments for user activities such as: end-user 
preference specifications for limiting the price per 
transaction, unit of time, and/or session, for 
accessing history information concerning previous 
transactions, for reviewing financial information 
such as budgets, expenditures (e.g. detailed and/or 
summary) and usage analysis information, and (c) 
VDE aware applications which, as a result of the use 
of a VDE API and/of a transaction management (for 
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example, ROS based) programming language 
embeds VDE "awareness* into commercial or 
internal software (application programs, games, etc.) 
so that VDE user control information and services 
are seamlessly integrated into such software and can 
be directly accessed by a user since the underlying 
functionality has been integrated into the 
commercial software's native design. For example, 
in a VDE aware word processor application, a user 
may be able to "print" a document into a VDE 
content container object, applying specific control 
information by selecting from amongst a series of 
different menu templates for different purposes (for 
example, a confidential memo template for internal 
organization purposes may restrict the ability to 
"keep," that is to make an electronic copy of the 
memo). 

employ "templates" to ease the process of configuring 
capabilities of the present invention as they relate to 
specific industries or businesses. Templates are 
applications or application add-ons under the 
present invention. Templates support the efficient 
specification and/or manipulation of criteria related 
to specific content types, distribution approaches, 
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pricing mechanisms, user interactions with content 
and/or administrative activities, and/or the like. 
Given the very large range of capabilities and 
configurations supported by the present invention, 
reducing the range of configuration opportunities to 
a manageable subset particularly appropriate for a 
given business model allows the full configurable 
power of the present invention to be easily employed 
by "typical" users who would be otherwise burdened 
with complex programming and/or configuration 
design responsibilities template applications can also 
help ensure that VDE related processes are secure 
and optimally bug free by reducing the risks 
associated with the contribution of independently 
developed load modules, including unpredictable 
aspects of code interaction between independent 
modules and applications, as well as security risks 
associated with possible presence of viruses in such 
modules. VDE, through the use of templates, 
reduces typical user configuration responsibilities to 
an appropriately focused set of activities including 
selection of method types (e.g. functionality) through 
menu choices such as multiple choice, icon selection, 
and/or prompting for method parameter data (such 
as identification information, prices, budget limit s, 
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dates, periods of time, access rights to specific 
content, etc.) that supply appropriate and/or 
necessary data for control information purposes. By 
limiting the typical (non-programming) user to a 
limited subset of configuration activities whose 
general configuration environment (template) has 
been preset to reflect general requirements 
corresponding to that user, or a content or other 
business model can very substantially limit 
difficulties associated with content containerization 
(including placing initial control information on 
content), distribution, client administration, 
electronic agreement implementation, end-user 
interaction, and clearinghouse activities, including 
associated interoperability problems (such as 
conflicts resulting from security, operating system, 
and/or certification incompatibilities). Use of 
appropriate VDE templates can assure users that 
their activities related to content VDE 
containerization, contribution of other control 
information, communications, encryption techniques 
and/or keys, etc. will be in compliance with 
specifications for their distributed VDE 
arrangement. VDE templates constitute preset 
configurations that can normally be reconfigurable 
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to allow for new and/or modified templates that 
reflect adaptation into new industries as they evolve 
or to reflect the evolution or other change of an 
existing industry. For example, the template 
concept may be used to provide individual, overall 
frameworks for organizations and individuals that 
create, modify, market, distribute, consume, and/or 
otherwise use movies, audio recordings and live 
performances, magazines, telephony based retail 
sales, catalogs, computer software, information data 
bases, multimedia, commercial communications, 
advertisements, market surveys, infomercials, 
games, CAD/CAM services for numerically controlled 
machines, and the like. As the context surrounding 
these templates changes or evolves, template 
applications provided under the present invention 
may be modified to meet these changes for broad 
use, or for more focused activities. A given VDE 
participant may have a plurality of templates 
available for different tasks. A party that places 
content in its initial VDE container may have a 
variety of different, configurable templates 
depending on the type of content and/or business 
model related to the content. An end-user may have 
different configurable templates that can be applied 
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to different document types (e-mail, secure interned 
documents, database records, etc.) and/or subsets of 
users (applying differing general sets of control 
information to different bodies of users, for example, 
selecting a list of users who may, under certain 
preset criteria, use a certain document). Of course, 
templates may, under certain circumstances have 
fixed control information and not provide for user 
selections or parameter data entry. 

support plural, different control models regulating 
the use and/or auditing of either the same specific 
copy of electronic information content and/or 
differently regulating different copies (occurrences) 
of the same electronic information content. Differing 
models for billing, auditing, and security can be 
applied to the same piece of electronic information 
content and such differing sets of control information 
may employ, for control purposes, the same, or 
differing, granularities of electronic information 
control increments. This includes supporting 
variable control information for budgeting and 
auditing usage as applied to a variety of predefined 
increments of electronic information, including 
employing a variety of different budgets and/or 
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metering increments for a given electronic 
information deliverable for: billing units of measure, 
credit limit, security budget limit and security 
content metering increments, and/or market 
surveying and customer profiling content metering 
increments. For example, a CD-ROM disk with a 
database of scientific articles might be in part billed 
according to a formula based on the number of bytes 
decrypted, number of articles containing said bytes 
decrypted, while a security budget might limit the 
use of said database to no more than 5% of the 
database per month for users on the wide area 
network it is installed on. 

provide mechanisms to persistently maintain trusted 
content usage and reporting control information 
through both a sufficiently secure chain of handling 
of content and content control information and 
through various forms of usage of such content 
wherein said persistence of control may survive such 
use. Persistence of control includes the ability to 
extract information from a VDE container object by 
creating a new container whose contents are at least 
in part secured and that contains both the extracted 
content and at least a portion of the control 
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information which control information of the original 
container and/or are at least in part produced by 
control information of the original container for this 
purpose and/or VDE installation control information 
stipulates should persist and/or control usage of 
content in the newly formed container. Such control 
information can continue to manage usage of 
container content if the container is "embedded* into 
another VDE managed object, such as an object 
which contains plural embedded VDE containers, 
each of which contains content derived (extracted) 
from a different source. 

enables users, other value chain participants (such 
as clearinghouses and government agencies), and/or 
user organizations, to specify preferences or 
requirements related to their use of electronic 
content and/or appliances. Content users, such as 
end-user customers using commercially distributed 
content (games, information resources, software 
programs, etc.), can define, if allowed by senior 
control information, budgets, and/or other control 
information, to manage their own internal use of 
content. Uses include, for example, a user setting a 
limit on the price for electronic documents that the 
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user is willing to pay without prior express user 
authorization, and the user establishing the 
character of metering information he or she is 
willing to allow to be collected (privacy protection). 
This includes providing the means for content users 
to protect the privacy of information derived from 
their use of a VDE installation and content and/or 
appliance usage auditing. In particular, VDE can 
prevent information related to a participant's usage 
of electronic content from being provided to other 
parties without the participant's tacit or explicit 
agreement. 

provide mechanisms that allow control information 
to "evolve" and be modified according, at least in 
part, to independently, securely delivered further 
control information. Said control information may 
include executable code (e.g., load modules) that has 
been certified as acceptable (e.g., reliable and 
trusted) for use with a specific VDE application, 
class of applications, and/or a VDE distributed 
arrangement. This modification (evolution) of 
control information can occur upon content control 
information (load modules and any associated data) 
circulating to one or more VDE participants in a 
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pathway of handling of control information, or it may 
occur upon control information being received from a 
VDE participant. Handlers in a pathway of 
handling of content control information, to the extent 
each is authorized, can establish, modify, and/or 
contribute to, permission, auditing, payment, and 
reporting control information related to controlling, 
analyzing, paying for, and/or reporting usage of, 
electronic content and/or appliances (for example, as 
related to usage of VDE controlled property content). 
Independently delivered (from an independent 
source which is independent except in regards to 
certification), at least in part secure, control 
information can be employed to securely modify 
content control information when content control 
information has flowed from one party to another 
party in a sequence of VDE content control 
information handling. This modification employs, 
for example, one or more VDE component assemblies 
being securely processed in a VDE secure subsystem. 
In an alternate embodiment, control information 
may be modified by a senior party through use of 
their VDE installation secure sub-system after 
receiving submitted, at least in part secured, control 
information from a "junior* party, normally in the 
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form of a VDE administrative object. Control 
information passing along VDE pathways can 
represent a mixed control set, in that it may include: 
control information that persisted through a 
5 sequence of control information handlers, other 

control information that was allowed to be modified, 
and further control information representing new 
control information and/or mediating data. Such a 
control set represents an evolution of control 
10 information for disseminated content. In this 

example the overall content control set for a VDE 
content container is "evolving" as it securely (e.g. 
communicated in encrypted form and using 
authentication and digital signaturing techniques) 
15 passes, at least in part, to a new participant's VDE 

installation where the proposed control information 
is securely received and handled. The received 
control information may be integrated (through use 
of the receiving parties' VDE installation secure 
20 sub-system) with in-place control information 

through a negotiation process involving both control 
information sets. For example, the modification, 
within the secure sub-system of a content provider's 
VDE installation, of content control information for a 
25 certain VDE content container may have occurred as 
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a result of the incorporation of required control 
information provided by a financial credit provider. 
Said credit provider may have employed their VDE 
installation to prepare and securely communicate 
(directly or indirectly) said required control 
information to said content provider. Incorporating 
said required control information enables a content 
provider to allow the credit provider's credit to be 
employed by a content end-user to compensate for 
the end-user's use of VDE controlled content and/or 
appliances, so long as said end-user has a credit 
account with said financial credit provider and said 
credit account has sufficient credit available. 
Similarly, control information requiring the payment 
of taxes and/or the provision of revenue information 
resulting from electronic commerce activities may be 
securely received by a content provider. This control 
information may be received, for example, from a 
government agency. Content providers might be 
required by law to incorporate such control 
information into the control information for 
commercially distributed content and/or services 
related to appliance usage. Proposed control 
information is used to an extent allowed by senior 
control information and as determined by any 
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negotiation trade-offs that satisfy priorities 
stipulated by each set (the received set and the 
proposed set). VDE also accommodates different 
control schemes specifically applying to different 
participants (e.g., individual participants and/or 
participant classes (types)) in a network of VDE 
content handling participants. 

support multiple simultaneous control models for the 
same content property and/or property portion. 
This allows, for example, for concurrent business 
activities which are dependent on electronic 
commercial product content distribution, such as 
acquiring detailed market survey information and/or 
supporting advertising, both of which can increase 
revenue and result in lower content costs to users 
and greater value to content providers. Such control 
information and/or overall control models may be 
applied, as determined or allowed by control 
information, in differing manners to different 
participants in a pathway of content, reporting, 
payment, and/or related control information 
handling. VDE supports applying different content 
control information to the same and/or different 
content and/or appliance usage related activities, 
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and/or to different parties in a content and/or 
appliance usage model, such that different parties 
(or classes of VDE users, for example) are subject to 
differing control information managing their use of 
electronic information content. For example, 
differing control models based on the category of a 
user as a distributor of a VDE controlled content 
object or an end-user of such content may result in 
different budgets being applied. Alternatively, for 
example, a one distributor may have the right to 
distribute a different array of properties than 
another distributor (from a common content 
collection provided, for example, on optical disc). An 
individual, and/or a class or other grouping of 
end-users, may have different costs (for example, a 
student, senior citizen, and/or poor citizen user of 
content who may be provided with the same or 
differing discounts) than a "typical" content user. 

support provider revenue information resulting from 
customer use of content and/or appliances, and/or 
provider and/or end-user payment of taxes, through 
the transfer of credit and/or electronic currency from 
said end-user and/or provider to a government 
agency, might occur "automatically" as a result of 
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such received control information causing the 
generation of a VDE content container whose 
content includes customer content usage information 
reflecting secure, trusted revenue summary 
information and/or detailed user transaction listings 
(level of detail might depend, for example on type or 
size of transaction — information regarding a bank 
interest payment to a customer or a transfer of a 
large (e.g. over $10,000) might be, by law, 
automatically reported to the government). Such 
summary and/or detailed information related to 
taxable events and/or currency, and/or creditor 
currency transfer, may be passed along a pathway of 
reporting and/or payment to the government in a 
VDE container. Such a container may also be used 
for other VDE related content usage reporting 
information. 

support the flowing of content control information 
through different "branches" of content control 
information handling so as to accommodate, under 
the present invention's preferred embodiment, 
diverse controlled distributions of VDE controlled 
content. This allows different parties to employ the 
same initial electronic content with differing 
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(perhaps competitive) control strategies. In this 
instance, a party who first placed control information 
on content can make certain control assumptions 
and these assumptions would evolve into more 
specific and/or extensive control assumptions. These 
control assumptions can evolve during the branching 
sequence upon content model participants 
submitting control information changes, for example, 
for use in "negotiating" with "in place* content 
control information. This can result in new or 
modified content control information and/or it might 
involve the selection of certain one or more already 
"in-place" content usage control methods over 
in-place alternative methods, as well as the 
submission of relevant control information 
parameter data. This form of evolution of different 
control information sets applied to different copies of 
the same electronic property content and/or 
appliance results from VDE control information 
flowing "down" through different branches in an 
overall pathway of handling and control and being 
modified differently as it diverges down these 
different pathway branches. This ability of the 
present invention to support multiple pathway 
branches for the flow of both VDE content control 
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information and VDE managed content enables an 
electronic commerce marketplace which supports 
diverging, competitive business partnerships, 
agreements, and evolving overall business models 
which can employ the same content properties 
combined, for example, in differing collections of 
content representing differing at least in part 
competitive products. 

enable a user to securely extract, through the use of 
the secure subsystem at the user's VDE installation, 
at least a portion of the content included within a 
VDE content container to produce a new, secure 
object (content container), such that the extracted 
information is maintained in a continually secure 
manner through the extraction process. Formation 
of the new VDE container containing such extracted 
content shall result in control information consistent 
with, or specified by, the source VDE content 
container, and/or local VDE installation secure 
subsystem as appropriate, content control 
information. Relevant control information, such as 
security and administrative information, derived, at 
least in part, from the parent (source) objects control 
information, will normally be automatically inserted 
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into a new VDE content container object containing 
extracted VDE content. This process typically occurs 
under the control framework of a parent object 
and/or VDE installation control information 
executing at the user's VDE installation secure 
subsystem (with, for example, at least a portion of 
this inserted control information being stored 
securely in encrypted form in one or more 
permissions records). In an alternative embodiment, 
the derived content control information applied to 
extracted content may be in part or whole derived 
from, or employ, content control information stored 
remotely from the VDE installation that performed 
the secure extraction such as at a remote server 
location. As with the content control information for 
most VDE managed content, features of the present 
invention allows the content's control information to: 

(a) "evolve," for example, the extractor of content 
may add new control methods and/or modify 
control parameter data, such as VDE 
application compliant methods, to the extent 
allowed by the content's in-place control 
information. Such new control information 
might specify, for example, who may use at 
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least a portion of the new object, and/or how 
said at least a portion of said extracted content 
may be used (e.g. when at least a portion may 
be used, or what portion or quantity of 
portions may be used); 

allow a user to combine additional content 
with at least a portion of said extracted 
content, such as material authored by the 
extractor and/or content (for example, images, 
video, audio, and/or text) extracted from one or 
more other VDE container objects for 
placement directly into the new container, 

allow a user to securely edit at least a portion 
of said content while maintaining said content 
in a secure form within said VDE content 
container; 

append extracted content to a pre-existing 
VDE content container object and attach 
associated control information - in these 
cases, user added information may be secured, 
e.g., encrypted, in part or as a whole, and may 
be subject to usage and/or auditing control 
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information that differs from the those applied 
to previously in place object content; 

(e) preserve VDE control over one or more 

portions of extracted content after various 
forms of usage of said portions, for example, 
maintain content in securely stored form while 
allowing "temporary" on screen display of 
content or allowing a software program to be 
maintained in secure form but transiently 
decrypt any encrypted executing portion of 
said program (all, or only a portion, of said 
program may be encrypted to secure the 
program). 

Generally, the extraction features of the present 
invention allow users to aggregate and/or 
disseminate and/or otherwise use protected 
electronic content information extracted from 
content container sources while maintaining secure 
VDE capabilities thus preserving the rights of 
providers in said content information after various 
content usage processes. 
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support the aggregation of portions of VDE 
controlled content, such portions being subject to 
differing VDE content container control information, 
wherein various of said portions may have been 
provided by independent, different content providers 
from one or more different locations remote to the 
user performing the aggregation. Such aggregation, 
in the preferred embodiment of the present 
invention, may involve preserving at least a portion 
of the control information (e.g., executable code such 
as load modules) for each of various of said portions 
by, for example, embedding some or all of such 
portions individually as VDE content container 
objects within an overall VDE content container 
and/or embedding some or all of such portions 
directly into a VDE content container. In the latter 
case, content control information of said content 
container may apply differing control information 
sets to various of such portions based upon said 
portions original control information requirements 
before aggregation. Each of such embedded VDE 
content containers may have its own control 
information in the form of one or more permissions 
records. Alternatively, a negotiation between control 
information associated with various aggregated 
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portions of electronic content, may produce a control 
information set that would govern some or all of the 
aggregated content portions. The VDE content 
control information produced by the negotiation may 
be uniform (such as having the same load modules 
and/or component assemblies, and/or it may apply 
differing such content control information to two or 
more portions that constitute an aggregation of VDE 
controlled content such as differing metering, 
budgeting, billing and/or payment models. For 
example, content usage payment may be 
automatically made, either through a clearinghouse, 
or directly, to different content providers for different 
potions. 

enable flexible metering of, or other collection of 
information related to, use of electronic content 
and/or electronic appliances. A feature of the 
present invention enables such flexibility of metering 
control mechanisms to accommodate a simultaneous, 
broad array of: (a) different parameters related to 
electronic information content use; (b) different 
increment units (bytes, documents, properties, 
paragraphs, images, etc.) and/or other organizations 
of such electronic content; and/or (c) different 
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categories of user and/or VDE installation types, 
such as client organizations, departments, projects, 
networks, and/or individual users, etc. This feature 
of the present invention can be employed for content 
5 security, usage analysis (for example, market 

surveying), and/or compensation based upon the use 
and/or exposure to VDE managed content. Such 
metering is a flexible basis for ensuring payment for 
content royalties, licensing, purchasing, and/or 

10 advertising. A feature of the present invention 

provides for payment means supporting flexible 
electronic currency and credit mechanisms, 
including the ability to securely maintain audit trails 
reflecting information related to use of such currency 

15 or credit. VDE supports multiple differing 

hierarchies of client organization control information 
wherein an organization client administrator 
distributes control information specifying the usage 
rights of departments, users, and/or projects. 

20 Likewise, a department (division) network manager 

can function as a distributor (budgets, access lights, 
etc.) for department networks, projects, and/or users, 
etc. 
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provide scalable, integratable, standardized control 
means for use on electronic appliances ranging from 
inexpensive consumer (for example, television 
set-top appliances) and professional devices (and 
hand-held PDAs) to servers, mainframes, 
communication switches, etc. The scalable 
transaction management/auditing technology of the 
present invention will result in more efficient and 
reliable interoperability amongst devices fimctioning 
in electronic commerce and/or data security 
environments. As standardized physical containers 
have become essential to the shipping of physical 
goods around the world, allowing these physical 
containers to universally "fit" unloading equipment, 
efficiently use truck and train space, and 
accommodate known arrays of objects (for example, 
boxes) in an efficient manner, so VDE electronic 
content containers may, as provided by the present 
invention, be able to efficiently move electronic 
information content (such as commercially published 
properties, electronic currency and credit, and 
content audit information), and associated content 
control information, around the world. 
Interoperability is fundamental to efficient electronic 
commerce. The design of the VDE foundation, VDE 
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load modules, and VDE containers, are important 
features that enable the VDE node operating 
environment to be compatible with a very broad 
range of electronic appliances. The ability, for 
example, for control methods based on load modules 
to execute in very "small" and inexpensive secure 
sub-system environments, such as environments 
with very little read/write memory, while also being 
able to execute in large memory sub-systems that 
may be used in more expensive electronic appliances, 
supports consistency across many machines. This 
consistent VDE operating environment, including its 
control structures and container architecture, 
enables the use of standardized VDE content 
containers across a broad range of device types and 
host operating environments. Since VDE 
capabilities can be seamlessly integrated as 
extensions, additions, and/or modifications to 
fundamental capabilities of electronic appliances and 
host operating systems, VDE containers, content 
control information, and the VDE foundation will be 
able to work with many device types and these 
device types will be able to consistently and 
efficiently interpret and enforce VDE control 
information. Through this integration users can also 
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benefit from a transparent interaction with many of 
the capabilities ofVDE. VDE integration with 
software operating on a host electronic appliance 
supports a variety of capabilities that would be 
unavailable or less secure without such integration. 
Through integration with one or more device 
applications and/or device operating environments, 
many capabilities of the present invention can be 
presented as inherent capabilities of a given 
electronic appliance, operating system, or appliance 
application. For example, features of the present 
invention include: (a) VDE system software to in 
part extend and/or modify host operating systems 
such that they possesses VDE capabilities, such as 
enabling secure transaction processing and 
electronic information storage; (b) one or more 
application programs that in part represent tools 
associated with VDE operation; and/or (c) code to be 
integrated into application programs, wherein such 
code incorporates references into VDE system 
software to integrate VDE capabilities and makes 
such applications VDE aware (for example, word 
processors, database retrieval applications, 
spreadsheets, multimedia presentation authoring 
tools, film editing software, music editing software 
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such as MIDI applications and the like, robotics 
control systems such as those associated with 
CAD/CAM environments and NCM software and the 
like, electronic mail systems, teleconferencing 
software, and other data authoring, creating, 
handling, and/or usage applications including 
combinations of the above). These one or more 
features (which may also be implemented in 
firmware or hardware) may be employed in 
conjunction with a VDE node secure hardware 
processing capability, such as a microcontroller(s), 
microprocessors), other CPU(s) or other digital 
processing logic. 

employ audit reconciliation and usage pattern 
evaluation processes that assess, through certain, 
normally network based, transaction processing 
reconciliation and threshold checking activities, 
whether certain violations of security of a VDE 
arrangement have occurred. These processes are 
performed remote to VDE controlled content 
end-user VDE locations by assessing, for example, 
purchases, and/or requests, for electronic properties 
by a given VDE installation. Applications for such 
reconciliation activities include assessing whether 
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the quantity of remotely delivered VDE controlled 
content corresponds to the amount of financial credit 
and/or electronic currency employed for the use of 
such content. A trusted organization can acquire 
information from content providers concerning the 
cost for content provided to a given VDE installation 
and/or user and compare this cost for content with 
the credit and/or electronic currency disbursements 
for that installation and/or user. Inconsistencies in 
the amount of content delivered versus the amount 
of disbursement can prove, and/or indicate, 
depending on the circumstances, whether the local 
VDE installation has been, at least to some degree, 
compromised (for example, certain important system 
security functions, such as breaking encryption for at 
least some portion of the secure subsystem and/or 
VDE controlled content by uncovering one or more 
keys). Determining whether irregular patterns (e.g. 
unusually high demand) of content usage, or 
requests for delivery of certain kinds of VDE 
controlled information during a certain time period 
by one or more VDE installations and/or users 
(including, for example, groups of related users 
whose aggregate pattern of usage is suspicious) may 
also be useful in determining whether security at 
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such one or more installations, and/or by such one or 
more users, has been compromised, particularly 
when used in combination with an assessment of 
electronic credit and/or currency provided to one or 
more VDE users and/or installations, by some or all 
of their credit and/or currency suppliers, compared 
with the disbursements made by such users and/or 
installations. 

support security techniques that materially increase 
the time required to "break" a system's integrity. 
This includes using a collection of techniques that 
minimizes the damage resulting from comprising 
some aspect of the security features of the present 
inventions. 

provide a family of authoring, administrative, 
reporting, payment, and billing tool user applications 
that comprise components of the present invention's 
trusted/secure, universe wide, distributed 
transaction control and administration system. 
These components support VDE related: object 
creation (including placing control information on 
content), secure object distribution and management 
(including distribution control information, financial 
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related, and other usage analysis), client internal 
VDE activities administration and control, security 
management, user interfaces, payment 
disbursement, and clearinghouse related functions. 
These components are designed to support highly 
secure, uniform, consistent, and standardized: 
electronic commerce and/or data security pathway(s) 
of handling, reporting, and/or payment; content 
control and administration; and human factors (e.g. 
user interfaces). 

support the operation of a plurality of 
clearinghouses, including, for example, both 
financial and user clearinghouse activities, such as 
those performed by a client administrator in a large 
organization to assist in the organization's use of a 
VDE arrangement, including usage information 
analysis, and control of VDE activities by individuals 
and groups of employees such as specifying budgets 
and the character of usage rights available under 
VDE for certain groups of and/or individual, client 
personnel, subject to control information series to 
control information submitted by the client 
administrator. At a clearinghouse, one or more VDE 
installations may operate together with a trusted 
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distributed database environment (which may 
include concurrent database processing means). A 
financial clearinghouse normally receives at its 
location securely delivered content usage 
5 information, and user requests (such as requests for 

further credit, electronic currency, and/or higher 
credit limit). Reporting of usage information and 
user requests can be used for supporting electronic 
currency, billing, payment and credit related 

10 activities, and/or for user profile analysis and/or 

broader market survey analysis and marketing 
(consolidated) list generation or other information 
derived, at least in part, from said usage 
information, this information can be provided to 

15 content providers or other parties, through secure, 

authenticated encrypted communication to the VDE 
installation secure subsystems. Clearinghouse 
processing means would normally be connected to 
specialized I/O means, which may include high speed 



20 telecommunication switching means that may be 

used for secure communications between a 
clearinghouse and other VDE pathway participants. 

! securely support electronic currency and credit 
25 usage control, storage, and communication at, and 
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between, VDE installations. VDE farther supports 
automated passing of electronic currency and/or 
credit information, including payment tokens (such 
as in the form of electronic currency or credit) or 
other payment information, through a pathway of 
payment, which said pathway may or may not be the 
same as a pathway for content usage information 
reporting. Such payment may be placed into a VDE 
container created automatically by a VDE 
installation in response to control information 
stipulating the "withdrawal" of credit or electronic 
currency from an electronic credit or currency 
account based upon an amount owed resulting from 
usage of VDE controlled electronic content and/or 
appliances. Payment credit or currency may then be 
automatically communicated in protected (at least in 
part encrypted) form through telecommunication of a 
VDE container to an appropriate party such as a 
clearinghouse, provider of original property content 
or appliance, or an agent for such provider (other . 
than a clearinghouse). Payment information may be 
packaged in said VDE content container with, or 
without, related content usage information, such as 
metering information. An aspect of the present 
invention further enables certain information 
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regarding currency use to be specified as unavailable 
to certain, some, or all VDE parties ("conditionally" 
to fully anonymous currency) and/or farther can 
regulate certain content information, such as 
currency and/or credit use related information 
(and/or other electronic information usage data) to be 
available only under certain strict circumstances, 
such as a court order (which may itself require 
authorization through the use of a court controlled 
VDE installation that may be required to securely 
access "conditionally" anonymous information). 
Currency and credit information, under the 
preferred embodiment of the present invention, is 
treated as administrative content; 

support fingerprinting (also known as 
watermarking) for embedding in content such that 
when content protected under the present invention 
is released in clear form from a VDE object 
(displayed, printed, communicated, extracted, and/or 
saved), information representing the identification of 
the user and/or VDE installation responsible for 
transforming the content into clear form is 
embedded into the released content. Fingerprinting 
is useful in providing an ability to identify who 
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extracted information in clear form a VDE container, 
or who made a copy of a VDE object or a portion of 
its contents. Since the identity of the user and/or 
other identifying information may be embedded in 
an obscure or generally concealed manner, in VDE 
container content and/or control information, 
potential copyright violators may be deterred from 
unauthorized extraction or copying. Fingerprinting 
normally is embedded into unencrypted electronic 
content or control information, though it can be 
embedded into encrypted content and later placed in 
unencrypted content in a secure VDE installation 
sub-system as the encrypted content carrying the 
fingerprinting information is decrypted. Electronic 
information, such as the content of a VDE container, 
may be fingerprinted as it leaves a network (such as 
Internet) location bound for a receiving party. Such 
repository information may be maintained in 
unencrypted form prior to communication and be 
encrypted as it leaves the repository. Fingerprinting 
would preferably take place as the content leaves the 
repository, but before the encryption step. 
Encrypted repository content can be decrypted, for 
example in a secure VDE sub-system, fingerprint 
information can be inserted, and then the content 
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can be re-encrypted for transmission. Embedding 
identification information of the intended recipient 
user and/or VDE installation into content as it 
leaves, for example, an Internet repository, would 
provide important information that would identify or 
assist in identifying any party that managed to 
compromise the security of a VDE installation or the 
delivered content. If a party produces an authorized 
clear form copy of VDE controlled content, including 
making unauthorized copies of an authorized clear 
form copy, fingerprint information would point back 
to that individual and/or his or her VDE installation. 
Such hidden information will act as a strong 
disincentive that should dissuade a substantial 
portion of potential content '"pirates" from stealing 
other parties electronic information. Fingerprint 
information identifying a receiving party and/or VDE 
installation can be embedded into a VDE object 
before, or during, decryption, replication, or 
communication of VDE content objects to receivers. 
Fingerprinting electronic content before it is 
encrypted for transfer to a customer or other user 
provides information that can be very useful for 
identifying who received certain content which may 
have then been distributed or made available in 
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unencrypted form. This information would be useful 
in tracking who may have "broken* the security of a 
VDE installation and was illegally making certain 
electronic content available to others. 
Fingerprinting may provide additional, available 
information such as time and/or date of the release 
(for example extraction) of said content information. 
Locations for inserting fingerprints may be specified 
by VDE installation and/or content container control 
information. This information may specify that 
certain areas and/or precise locations within 
properties should be used for fingerprinting, such as 
one or more certain fields of information or 
information types. Fingerprinting information may 
be incorporated into a property by modifying in a 
normally undetectable way color frequency and/or 
the brightness of certain image pixels, by slightly 
modifying certain audio signals as to frequency, by 
modifying font character formation, etc. Fingerprint 
information, itself, should be encrypted so as to 
make it particularly difficult for tampered 
fingerprints to be interpreted as valid. Variations in 
fingerprint locations for different copies of the same 
property; "false" fingerprint information; and 
multiple copies of fingerprint information within a 
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specific property or other content which copies 
employ different fingerprinting techniques such as 
information distribution patterns, frequency and/or 
brightness manipulation, and encryption related 
techniques, are features of the present invention for 
increasing the difficulty of an unauthorized 
individual identifying fingerprint locations and 
erasing and/or modifying fingerprint information. 

provide smart object agents that can carry requests, 
data, and/or methods, including budgets, 
authorizations, credit or currency, and content. For 
example, smart objects may travel to and/or from 
remote information resource locations and fulfill 
requests for electronic information content. Smart 
objects can, for example, be transmitted to a remote 
location to perform a specified database search on 
behalf of a user or otherwise "intelligently" search 
remote one or more repositories of information for 
user desired information. After identifying desired 
information at one or more remote locations, by for 
example, performing one or more database searches, 
a smart object may return via communication to the 
user in the form of a secure "return object* 
containing retrieved information. A user may be 
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charged for the remote retrieving of information, the 
returning of information to the user's VDE 
installation, and/or the use of such information. In 
the latter case, a user may be charged only for the 
information in the return object that the user 
actually uses. Smart objects may have the means to 
request use of one or more services and/or resources. 
Services include locating other services and/or 
resources such as information resources, language or 
format translation, processing, credit (or additional 
credit) authorization, etc. Resources include 
reference databases, networks, high powered or 
specialized computing resources (the smart object 
may carry information to another computer to be 
efficiently processed and then return the information 
to the sending VDE installation), remote object 
repositories, etc. Smart objects can make efficient 
use of remote resources (e.g. centralized databases, 
super computers, etc.) while providing a secure 
means for charging users based on information 
and/or resources actually used. 

support both "translations" of VDE electronic 
agreements elements into modern language printed 
agreement elements (such as English language 
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agreements) and translations of electronic rights 
protection/transaction management modern 
language agreement elements to electronic VDE 
agreement elements. This feature requires 
maintaining a library of textual language that 
corresponds to VDE load modules and/or methods 
and/or component assemblies. As VDE methods are 
proposed and/or employed for VDE agreements, a 
listing of textual terms and conditions can be 
produced by a VDE user application which, in a 
preferred embodiment, provides phrases, sentences 
and/or paragraphs that have been stored and 
correspond to said methods and/or assemblies. This 
feature preferably employs artificial intelligence 
capabilities to analyze and automatically determine, 
and/or assist one or more users to determine, the 
proper order and relationship between the library 
elements corresponding to the chosen methods 
and/or assemblies so as to compose some or all 
portions of a legal or descriptive document. One or 
more users, and/or preferably an attorney (if the 
document a legal, binding agreement), would review 
the generated document material upon completion 
and employ such additional textual information 
and/or editing as necessary to describe non electronic 
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transaction elements of the agreement and make 
any other improvements that may be necessary. 
These features further support employing modern 
language tools that allow one or more users to make 
selections from choices and provide answers to 
questions and to produce a VDE electronic 
agreement from such a process. This process can be 
interactive and the VDE agreement formulation 
process may employ artificial intelligence expert 
system technology that learns from responses and, 
where appropriate and based at least in part on said 
responses, provides further choices and/or questions 
which "evolves" the desired VDE electronic 
agreement. 

support the use of multiple VDE secure subsystems 
in a single VDE installation. Various security and/or 
performance advantages may be realized by 
employing a distributed VDE design within a single 
VDE installation. For example, designing a 
hardware based VDE secure subsystem into an 
electronic appliance VDE display device, and 
designing said subsystem's integration with said 
display device so that it is as close as possible to the 
point of display, will increase the security for video 
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materials by making it materially more difficult to 
"steal" decrypted video information as it moves from 
outside to inside the video system. Ideally, for 
example, a VDE secure hardware module would be 
in the same physical package as the actual display 
monitor, such as within the packaging of a video 
monitor or other display device, and such device 
would be designed, to the extent commercially 
practical, to be as tamper resistant as reasonable. 
As another example, embedding a VDE hardware 
module into an I/O peripheral may have certain 
advantages from the standpoint of overall system 
throughput. If multiple VDE instances are employed 
within the same VDE installation, these instances 
will ideally share resources to the extent practical, 
such as VDE instances storing certain control 
information and content and/or appliance usage 
information on the same mass storage device and in 
the same VDE management database. 

requiring reporting and payment compliance by 
employing exhaustion of budgets and time ageing of 
keys. For example, a VDE commercial arrangement 
and associated content control information may 
involve a content provider's content and the use of 
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clearinghouse credit for payment for end-user usage 
of said content. Control information regarding said 
arrangement may be delivered to a user's (of said 
content) VDE installation and/or said financial 
clearinghouse's VDE installation. Said control 
information might require said clearinghouse to 
prepare and telecommunicate to said content 
provider both content usage based information in a 
certain form, and content usage payment in the form 
of electronic credit (such credit might be "owned" by 
the provider after receipt and used in lieu of the 
availability or adequacy of electronic currency) 
and/or electronic currency. This delivery of 
information and payment may employ trusted VDE 
installation secure subsystems to securely, and in 
some embodiments, automatically, provide in the 
manner specified by said control information, said 
usage information and payment content. Features of 
the present invention help ensure that a 
requirement that a clearinghouse report such usage 
information and payment content will be observed. 
For example, if one participant to a VDE electronic 
agreement fails to observe such information 
reporting and/or paying obligation, another 
participant can stop the delinquent party from 



-114- 



PCT/US96/02303 



successfully participating in VDE activities related 
to such agreement. For example, if required usage 
information and payment was not reported as 
specified by content control information, the 
"injured" party can fail to provide, through failing to 
securely communicate from his VDE installation 
secure subsystem, one or more pieces of secure 
information necessary for the continuance of one or 
more critical processes. For example, failure to 
report information and/or payment from a 
clearinghouse to a content provider (as well as any 
security failures or other disturbing irregularities) 
can result in the content provider not providing key 
and/or budget refresh information to the 
clearinghouse, which information can be necessary 
to authorize use of the clearinghouse's credit for 
usage of the provider's content and which the 
clearinghouse would communicate to end-user's 
during a content usage reporting communication 
between the clearinghouse and end-user. As another 
example, a distributor that failed to make payments 
and/or report usage information to a content 
provider might find that their budget for creating 
permissions records to distribute the content 
provider's content to users, and/or a security budget 
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limiting one or more other aspect of their use of the 
provider's content, are not being refreshed by the 
content provider, once exhausted or timed-out (for 
example, at a predetermined date). In these and 
other cases, the offended party might decide not to 
refresh time ageing keys that had "aged out." Such a 
use of time aged keys has a similar impact as failing 
to refresh budgets or time-aged authorizations. 

support smart card implementations of the present 
invention in the form of portable electronic 
appliances, including cards that can be employed as 
secure credit, banking, and/or money cards. A 
feature of the present invention is the use of portable 
VDEs as transaction cards at retail and other 
establishments, wherein such cards can "dock" with 
an establishment terminal that has a VDE secure 
sub-system and/or an online connection to a VDE 
secure and/or otherwise secure and compatible 
subsystem, such as a "trusted" financial 
clearinghouse (e.g., VISA, Mastercard). The VDE 
card and the terminal (and/or online connection) can 
securely exchange information related to a 
transaction, with credit and/or electronic currency 
being transferred to a merchant and/or 
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clearinghouse and transaction information flowing 
back to the card. Such a card can be used for 
transaction activities of all sorts. A docking station, 
such as a PCMCIA connector on an electronic 
appliance, such as a personal computer, can receive 
a consumer's VDE card at home. Such a station/card 
combination can be used for on-line transactions in 
the same manner as a VDE installation that is 
permanently installed in such an electronic 
appliance. The card can be used as an "electronic 
wallet" and contain electronic currency as well as 
credit provided by a clearinghouse. The card can act 
as a convergence point for financial activities of a 
consumer regarding many, if not all, merchant, 
banking, and on-line financial transactions, 
including supporting home banking activities. A 
consumer can receive his paycheck and/or 
investment earnings and/or "authentic" VDE content 
container secured detailed information on such 
receipts, through on-line connections. A user can 
send digital currency to another party with a VDE 
arrangement, including giving away such currency. 
A VDE card can retain details of transactions in a 
highly secure and database organized fashion so that 
financially related information is both consolidated 
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and very easily retrieved and/or analyzed. Because 
of the VDE security, including use of effective 
encryption, authentication, digital signaturing, and 
secure database structures, the records contained 
within a VDE card arrangement may be accepted as 
valid transaction records for government and/or 
corporate recordkeeping requirements. In some 
embodiments of the present invention a VDE card 
may employ dockiiig station and/or electronic 
appliance storage means and/or share other VDE 
arrangement means local to said appliance and/or 
available across a network, to augment the 
information storage capacity of the VDE card, by for 
example, storing dated, and/or archived, backup 
information. Taxes relating to some or all of an 
individual's financial activities may be automatically 
computed based on "authentic" information securely 
stored and available to said VDE card. Said 
information may be stored in said card, in said 
docking station, in an associated electronic 
appliance, and/or other device operatively attached 
thereto, and/or remotely, such as at a remote server 
site. A card's data, e.g. transaction history, can be 
backed up to an individual's personal computer or 
other electronic appliance and such an appliance 
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may have an integrated VDE installation of its own. 
A current transaction, recent transactions (for 
redundancy), or all or other selected card data may 
be backed up to a remote backup repository, such a 
VDE compatible repository at a financial 
clearinghouse, during each or periodic docking for a 
financial transaction and/or information 
communication such as a user/merchant transaction. 
Backing up at least the current transaction during a 
connection with another party's VDE installation 
(for example a VDE installation that is also on a 
financial or general purpose electronic network), by 
posting transaction information to a remote 
clearinghouse and/or bank, can ensure that 
sufficient backup is conducted to enable complete 
reconstruction of VDE card internal information in 
the event of a card failure or loss. 

support certification processes that ensure 
authorized interoperability between various VDE 
installations so as to prevent VDE arrangements 
and/or installations that unacceptably deviate in 
specification protocols from other VDE arrangements 
and/or installations from interoperating in a manner 
that may introduce security (integrity and/or 
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confidentiality of VDE secured information), process 
control, and/or software compatibility problems. 
Certification validates the identity of VDE 
installations and/or their components, as well as 
VDE users. Certification data can also serve as 
information that contributes to determining the 
decommissioning or other change related to VDE 
sites. 

support the separation of fundamental transaction 
control processes through the use of event (triggered) 
based method control mechanisms. These event 
methods trigger one or more other VDE methods 
(which are available to a secure VDE sub-system) 
and are used to carry out VDE managed transaction 
related processing. These triggered methods include 
independently (separably) and securely processable 
component b illing management methods, budgeting 
management methods, metering management 
methods, and related auditing management 
processes. As a result of this feature of the present 
invention, independent triggering of metering, 
auditing, billing, and budgeting methods, the 
present invention is able to efficiently, concurrently 
support multiple financial currencies (e.g. dollars, 
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marks, yen) and content related budgets, and/or 
billing increments as well as very flexible content 
distribution models. 

support, complete, modular separation of the control 
structures related to (1) content event triggering, (2) 
auditing, (3) budgeting (including specifying no right 
of use or unlimited right of use), (4) billing, and (5) 
user identity (VDE installation, client name, 
department, network, and/or user, etc.). The 
independence of these VDE control structures 
provides a flexible system which allows plural 
relationships between two or more of these 
structures, for example, the ability to associate a 
financial budget with different event trigger 
structures (that are put in place to enable controlling 
content based on its logical portions). Without such 
separation between these basic VDE capabilities, it 
would be more difficult to efficiently maintain 
separate metering, budgeting, identification, and/or 
billing activities which involve the same, differing 
(including overlapping), or entirely different, 
portions of content for metering, billing, budgeting, 
and user identification, for example, paying fees 
associated with usage of content, performing home 
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banking, managing advertising services, etc. VDE 
modular separation of these basic capabilities 
supports the programming of plural, "arbitrary" 
relationships between one or differing content 
portions (and/or portion units) and budgeting, 
auditing, and/or billing control information. For 
example, under VDE, a budget limit of $200 dollars 
or 300 German Marks a month may be enforced for 
decryption of a certain database and 2 U.S. Dollars 
or 3 German Marks may be charged for each record 
of said database decrypted (depending on user 
selected currency). Such usage can be metered while 
an additional audit for user profile purposes can be 
prepared recording the identity of each filed 
displayed. Additionally, further metering can be 
conducted regarding the number of said database 
bytes that have been decrypted, and a related 
security budget may prevent the decrypting of more 
than 5% of the total bytes of said database per year. 
The user may also, under VDE (if allowed by senior 
control information), collect audit information 
reflecting usage of database fields by different 
individuals and client organization departments and 
ensure that differing rights of access and differing 
budgets limiting database usage can be applied to 
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these client individuals and groups. Enabling 
content providers and users to practically employ 
such diverse sets of user identification, metering, 
budgeting, and billing control information results, in 
part, from the use of such independent control 
capabilities. As a result, VDE can support great 
configurability in creation of plural control models 
applied to the same electronic property and the same 
and/or plural control models applied to differing or 
entirely different content models (for example, home 
banking versus electronic shopping). 

Methods, Other Control Information, and VDE Objects 

VDE control information (e.g., methods) that collectively 
control use of VDE managed properties (database, document, 
individual commercial product), are either shipped with the 
content itself (for example, in a content container) and/or one or 
more portions of such control information is shipped to 
distributors and/or other users in separably deliverable 
"administrative objects." A subset of the methods for a property 
may in part be delivered with each property while one or more 
other subsets of methods can be delivered separately to a user or 
otherwise made available for use (such as being available 
remotely by telecommunication means). Required methods 
(methods listed as required for property and/or appliance use) 
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must be available as specified if VDE controlled content (such as 
intellectual property distributed within a VDE content container) 
is to be used. Methods that control content may apply to a 
plurality of VDE container objects, such as a class or other 
5 grouping of such objects. Methods may also be required by 

certain users or classes of users and/or VDE installations and/or 
classes of installations for such parties to use one or more 
specific, or classes of, objects. 

10 A feature of VDE provided by the present invention is that 

certain one or more methods can be specified as required in order 
for a VDE installation and/or user to be able to use certain and/or 
all content. For example, a distributor of a certain type of 
content might be allowed by "senior' 5 participants (by content 

15 creators, for example) to require a method which prohibits 

end-users from electronically saving decrypted content, a 
provider of credit for VDE transactions might require an audit 
method that records the time of an electronic purchase, and/or a 
user might require a method that summarizes usage information 

20 for reporting to a clearinghouse (e.g. billing information) in a way 

that does not convey confidential, personal information regarding 
detailed usage behavior. 

A further feature of VDE provided by the present invention 
25 is that creators, distributors, and users of content can select from 
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among a set of predefined methods (if available) to control 
container content usage and distribution functions and/or they 
may have the right to provide new customized methods to control 
at least certain usage functions (such "new* methods may be 
5 required to be certified for trustedness and interoperability to the 

VDE installation and/or for of a group of VDE applications). As a 
result, VDE provides a very high degree of configurability with 
respect to how the distribution and other usage of each property 
or object (or one or more portions of objects or properties as 
10 desired and/or applicable) will be controlled. Each VDE 

participant in a VDE pathway of content control information may 
set methods for some or all of the content in a VDE container, so 
long as such control information does not conflict with senior 
control information already in place with respect to: 



15 



20 



(1) certain or all VDE managed content, 

(2) certain one or more VDE users and/or groupings of 
users, 

(3) certain one or more VDE nodes and/or groupings of 
nodes, and/or 



(4) certain one or more VDE applications and/or 
25 arrangements. 
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For example, a content creator's VDE control information 
for certain content can take precedence over other submitted 
VDE participant control information and, for example, if allowed 
by senior control information, a content distributor's control 
information may itself take precedence over a client 
administrator's control information, which may take precedence 
over an end-user's control information. A path of distribution 
participant's ability to set such electronic content control 
information can be limited to certain control information (for 
example, method mediating data such as pricing and/or sales 
dates) or it may be limited only to the extent that one or more of 
the participant's proposed control information conflicts with 
control information set by senior control information submitted 
previously by participants in a chain of handling of the property, 
or managed in said participant's VDE secure subsystem. 

VDE control information may, in part or in full, (a) . 
represent control information directly put in place by VDE 
content control information pathway participants, and/or (b) 
comprise control information put in place by such a participant 
on behalf of a party who does not directly handle electronic 
content (or electronic appliance) permissions records information 
(for example control information inserted by a participant on 
behalf of a financial clearinghouse or government agency). Such 
control information methods (and/or load modules and/or 
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mediating data and/or component assemblies) may also be put in 
place by either an electronic automated, or a semi-automated and 
human assisted, control information (control set) negotiating 
process that assesses whether the use of one or more pieces of 
submitted control information will be integrated into and/or 
replace existing control information (and/or chooses between 
alternative control information based upon interaction with 
in-place control information) and how such control information 
may be used. 

Control information may be provided by a party who does 
not directly participate in the handling of electronic content 
(and/or appliance) and/or control information for such content 
(and/or appliance). Such control information may be provided in 
secure form using VDE installation secure sub-system managed 
communications (including, for example, authenticating the 
deliverer of at least in part encrypted control information) 
between such not directly participating one or more parties' VDE 
installation secure subsystems, and a pathway of VDE content 
control information participant's VDE installation secure 
subsystem. This control information may relate to, for example, 
the right to access credit supplied by a financial services 
provider, the enforcement of regulations or laws enacted by a 
government agency, or the requirements of a customer of VDE 
managed content usage information (reflecting usage of content 
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by one or more parties other than such customer) relating to the 
creation, handling and/or manner of reporting of usage 
information received by such customer. Such control information 
may, for example, enforce societal requirements such as laws 
related to electronic commerce. 

VDE content control information may apply differently to 
different pathway of content and/or control information handling 
participants. Furthermore, permissions records rights may be 
added, altered, and/or removed by a VDE participant if they are 
allowed to take such action. Rights of VDE participants may be 
defined in relation to specific parties and/or categories of parties 
and/or other groups of parties in a chain of handling of content 
and/or content control information (e.g., permissions records). 
Modifications to control information that may be made by a 
given, eligible party or parties, may be limited in the number of 
modifications, and/or degree of modification, they may make. 

At least one secure subsystem in electronic appliances of 
creators, distributors, auditors, clearinghouses, client 
administrators, and end-users (understanding that two or more . 
of the above classifications may describe a single user) provides a 
"sufficiently" secure (for the intended applications) environment 
for: 
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1. Decrypting properties and control information; 

2. Storing control and metering related information; 

3. Managing communications; 

4. Processing core control programs, along with 
associated data, that constitute control information 
for electronic content and/or appliance rights 
protection, including the enforcing of preferences 
and requirements of VDE participants. 

Normally, most usage, audit, reporting, payment, and 
distribution control methods are themselves at least in part 
encrypted and are executed by the secure subsystem of a VDE 
installation. Thus, for example, billing and metering records can 
be securely generated and updated, and encryption and 
decryption keys are securely utilized, within a secure subsystem. 
Since VDE also employs secure (e.g. encrypted and 
authenticated) communications when passing information 
between the participant location (nodes) secure subsystems of a 
VDE arrangement, important components of a VDE electronic 
agreement can be reliably enforced with sufficient security 
(sufficiently trusted) for the intended commercial purposes. A 
VDE electronic agreement for a value chain can be composed, at 
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least in part, of one or more subagreements between one or more 
subsets of the value chain participants. These subagreements 
are comprised of one or more electronic contract "compliance" 
elements (methods including associated parameter data) that 
ensure the protection of the rights of VDE participants. 

The degree of trustedness of a VDE arrangement will be 
primarily based on whether hardware SPUs are employed at 
participant location secure subsystems and the effectiveness of 
the SPU hardware security architecture, software security 
techniques when an SPU is emulated in software, and the 
encryption algorithm(s) and keys that are employed for securing 
content, control information, communications, and access to VDE 
node (VDE installation) secure subsystems. Physical facility and 
user identity authentication security procedures may be used 
instead of hardware SPUs at certain nodes, such as at an 
established financial clearinghouse, where such procedures may 
provide sufficient security for trusted interoperability with a 
VDE arrangement employing hardware SPUs at user nodes. 

The updating of property management files at each 
location of a VDE arrangement, to accommodate new or modified 
control information, is performed in the VDE secure subsystem 
and under the control of secure management file updating 
programs executed by the protected subsystem. Since all secure 
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communications are at least in part encrypted and the processing 
inside the secure subsystem is concealed from outside 
observation and interference, the present invention ensures that 
content control information can be enforced. As a result, the 
creator and/or distributor and/or client administrator and/or 
other contributor of secure control information for each property 
(for example, an end-user restricting the kind of audit 
information he or she will allow to be reported and/or a financial 
clearinghouse establishing certain criteria for use of its credit for 
payment for use of distributed content) can be confident that 
their contributed and accepted control information will be 
enforced (within the security limitations of a given VDE security 
implementation design). This control information can determine, 
for example: 

( 1) How and/or to whom electronic content can be 
provided, for example, how an electronic property 
can be distributed; 

(2) How one or more objects and/or properties, or 

_ portions of an object or property, can be directly 

used, such as decrypted, displayed, printed, etc; 

(3) How payment for usage of such content and/or 
content portions may or must be handled; and 
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(4) How audit information about usage information 

related to at least a portion of a property should be 
collected, reported, and/or used. 

Seniority of contributed control information, including 
resolution of conflicts between content control information 
submitted by multiple parties, is normally established by: 



(1) the sequence in which control information is put in 
place by various parties (in place control information 
normally takes precedence over subsequently 
submitted control information), 



(2) the specifics of VDE content and/or appliance control 
information. For example, in-place control 
information can stipulate which subsequent one or 
more piece of control from one or more parties or 
class of parties will take precedence over control 
information submitted by one or more yet different 
parties and/or classes of parties, and/or 

(3) negotiation between control information sets from 
plural parties, which negotiation establishes what 
control information shall constitute the resulting 
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control information set for a given piece of VDE 
managed content and/or VDE installation. 

Electronic Agreements and Rights Protection 

An important feature of VDE is that it can be used to 
assure the administration of, and adequacy of security and rights 
protection for, electronic agreements implemented through the 
use of the present invention. Such agreements may involve one 
or more of: 

(1) creators, publishers, and other distributors, of 
electronic information, 

(2) financial service (e.g. credit) providers, 

(3) users of (other than financial service providers) 
information arising from content usage such as 
content specific demographic information and user 
specific descriptive information. Such users may 
include market analysts, marketing list compilers for 
direct and directed marketing, and government 
agencies, 

(4) end users of content, 
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(5) infrastructure service and device providers such as 
telecommunication companies and hardware 
manufacturers (semiconductor and electronic 
appliance and/or other computer system 
manufacturers) who receive compensation based 
upon the use of their services and/or devices, and 

(6) certain parties described by electronic information. 

VDE supports commercially secure "extended" value chain 
electronic agreements. VDE can be configured to support the 
various underlying agreements between parties that comprise 
this extended agreement. These agreements can define 
important electronic commerce considerations including: 

(1) security, 

(2) content use control, including electronic distribution, 

(3) privacy (regarding, for example, information 
concerning parties described by medical, credit, tax, 
personal, and/or of other forms of confidential 
information), 

(4) management of financial processes, and 
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(5) pathways of handling for electronic content, content 
and/or appliance control information, electronic 
content and/or appliance usage information and 
payment and/or credit. 

VDE agreements may define the electronic commerce 
relationship of two or more parties of a value chain, but such 
agreements may, at times, not directly obligate or otherwise 
directly involve other VDE value chain participants. For 
example, an electronic agreement between a content creator and 
a distributor may establish both the price to the distributor for a 
creator's content (such as for a property distributed in a VDE 
container object) and the number of copies of this object that this 
distributor may distribute to end-users over a given period of 
time. In a second agreement, a value chain end-user may be 
involved in a three party agreement in which the end-user agrees 
to certain requirements for using the distributed product such as 
accepting distributor charges for content use and agreeing to 
observe the copyright rights of the creator. A third agreement 
might exist between the distributor and a financial clearinghouse 
that allows the distributor to employ the clearinghouse's credit 
for payment for the product if the end-user has a separate 
(fourth) agreement directly with the clearinghouse extending 
credit to the end-user. A fifth, evolving agreement may develop 
between all value chain participants as content control 
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information passes along its chain of handling. This evolving 
agreement can establish the rights of all parties to content usage 
information, including, for example, the nature of information to 
be received by each party and the pathway of handling of content 
usage information and related procedures. A sixth agreement in 
this example, may involve all parties to the agreement and 
establishes certain general assumptions, such as security 
techniques and degree of trustedness (for example, commercial 
integrity of the system may require each VDE installation secure 
subsystem to electronically warrant that their VDE node meets 
certain interoperability requirements). In the above example, 
these six agreements could comprise agreements of an extended 
agreement for this commercial value chain instance. 

VDE agreements support evolving ("living") electronic 
agreement arrangements that can be modified by current and/or 
new participants through very simple to sophisticated 
"negotiations" between newly proposed content control 
information interacting with control information already in place 
and/or by negotiation between concurrently proposed content 
control information submitted by a plurality of parties. A given 
model may be asynchronously and progressively modified over 
time in accordance with existing senior rules and such 
modification may be applied to all, to classes of, and/or to specific 
content, and/or to classes and/or specific users and/or user nodes. 
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A given piece of content may be subject to different control 
information at different times or places of handling, depending on 
the evolution of its content control information (and/or on 
differing, applicable VDE installation content control 
information). The evolution of control information can occur 
during the passing along of one or more VDE control information 
containing objects, that is control information may be modified at 
one or more points along a chain of control information handling, 
so long as such modification is allowed. As a result, VDE 
managed content may have different control information applied 
at both different 'locations" in a chain of content handling and at 
similar locations in differing chains of the handling of such 
content. Such different application of control information may 
also result from content control information specifying that a 
certain party or group of parties shall be subject to content 
control information that differs from another party or group of 
parties. For example, content control information for a given 
piece of content may be stipulated as senior information and 
therefore not changeable, might be put in place by a content 
creator and might stipulate that national distributors of a given 
piece of their content may be permitted to make 100,000 copies 
per calendar quarter, so long as such copies are provided to boni 
fide end-users, but may pass only a single copy of such content to 
a local retailers and the control information limits such a retailer 
to making no more than 1,000 copies per month for retail sales to 
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end-users. In addition, for example, an end-user of such content 
might be limited by the same content control information to 
making three copies of such content, one for each of three 
different computers he or she uses (one desktop computer at 
5 work, one for a desktop computer at home, and one for a portable 

computer). 

Electronic agreements supported by the preferred 
embodiment of the present invention can vary from very simple 
10 to very elaborate. They can support widely diverse information 

management models that provide for electronic information 
security, usage administration, and communication and may 
support: 

15 

(a) secure electronic distribution of information, for 
example commercial literary properties, 

(b) secure electronic information usage monitoring and 
20 reporting, 



(c) secure finan cial transaction capabilities related to 
both electronic information and/or appliance usage 
and other electronic credit and/or currency usage 
25 and administration capabilities, 
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privacy protection for usage information a user does 
not wish to release, and 

"living* electronic information content dissemination 
models that flexibly accommodate: 

(1) a breadth of participants, 

(2) one or more pathways (chains) for: the 
handling of content, content and/or appliance 
control information, reporting of content 
and/or appliance usage related information, 
and/or payment, 

(3) supporting an evolution of terms and 
conditions incorporated into content control 
information, including use of electronic 
negotiation capabilities, 

(4) support the combination of multiple pieces of 
content to form new content aggregations, and 

(5) multiple concurrent models. 
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Secure Processing Units 

An important part of VDE provided by the present 
invention is the core secure transaction control arrangement, 
herein called an SPU (or SPUs), that typically must be present in 
each user's computer, other electronic appliance, or network. 
SPUs provide a trusted environment for generating decryption 
keys, encrypting and decrypting information, managing the 
secure communication of keys and other information between 
electronic appliances (i.e. between VDE installations and/or 
between plural VDE instances within a single VDE installation), 
securely accumulating and managing audit trail, reporting, and 
budget information in secure and/or non-secure non-volatile 
memory, maintaining a secure database of control information 
management instructions, and providing a secure environment 
for perfor min g certain other control and administrative functions. 

A hardware SPU (rather than a software emulation) within 
a VDE node is necessary if a highly trusted environment for 
performing certain VDE activities is required. Such a trusted 
environment may be created through the use of certain control 
software, one or more tamper resistant hardware modules such 
as a semiconductor or semiconductor chipset (including, for 
example, a tamper resistant hardware electronic appliance 
peripheral device), for use within, and/or operatively connected 
to, an electronic appliance. With the present invention, the 
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trustedness of a hardware SPU can be enhanced by enclosing 
some or all of its hardware elements within tamper resistant 
packaging and/or by employing other tamper resisting techniques 
(e.g. microfusing and/or thin wire detection techniques). A 
trusted environment of the present invention implemented, in 
part, through the use of tamper resistant semiconductor design, 
contains control logic, such as a microprocessor, that securely 
executes VDE processes. 

A VDE node's hardware SPU is a core component of a VDE 
secure subsystem and may employ some or all of an electronic 
appliance's primary control logic, such as a microcontroller, 
microcomputer or other CPU arrangement. This primary control 
logic may be otherwise employed for non VDE purposes such as 
the control of some or all of an electronic appliance's non-VDE 
functions. When operating in a hardware SPU mode, said 
primary control logic must be sufficiently secure so as to protect 
and conceal important VDE processes. For example, a hardware 
SPU may employ a host electronic appliance microcomputer 
operating in protected mode while performing VDE related 
activities, thus allowing portions of VDE processes to execute 
with a certain degree of security. This alternate embodiment is 
in contrast to the preferred embodiment wherein a trusted 
environment is created using a combination of one or more 
tamper resistant semiconductors that are not part of said 
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primary control logic. In either embodiment, certain control 
information (software and parameter data) must be securely 
maintained within the SPU, and further control information can 
be stored externally and securely (e.g. in encrypted and tagged 
5 form) and loaded into said hardware SPU when needed. In many 

cases, and in particular with microcomputers, the preferred 
embodiment approach of employing special purpose secure 
hardware for executing said VDE processes, rather than using 
said primary control logic, may be more secure and efficient. The 
10 level of security and tamper resistance required for trusted SPU 

hardware processes depends on the commercial requirements of 
particular markets or market niches, and may vary widely. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages provided by the 
present invention(s) may be better and more completely 
understood by referring to the following detailed description of 
presently preferred example embodiments in connection with the 
drawings, of which: 

FIGURE 1 illustrates an example of a "Virtual Distribution 
Environment" provided in accordance with a preferred 
example/embodiment of this invention; 

FIGURE 1A is a more detailed illustration of an example of 
the "Information Utility" shown in FIGURE 1; 

FIGURE 2 illustrates an example of a chain of handling 
and control; 

FIGURE 2 A illustrates one example of how rules and 
control information may persist from one participant to another 
in the Figure 2 chain of handling and control; 
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FIGURE 3 shows one example of different control 
information that may be provided; 

FIGURE 4 illustrates examples of some different types of 
5 rules and/or control information; 

FIGURES 5A and 5B show an example of an "object"; 

FIGURE 6 shows an example of a Secure Processing Unit 
10 ("SPIT); 

FIGURE 7 shows an example of an electronic appliance; 

FIGURE 8 is a more detailed block diagram of an example 
15 of the electronic appliance shown in FIGURE 7; 

FIGURE 9 is a detailed view of an example of the Secure 
Processing Unit (SPU) shown in FIGURES 6 and 8; 

20 FIGURE 10 shows an example of a "Rights Operating 

System" ("ROS") architecture provided by the Virtual 
Distribution Environment; 



-144- 



WO 96/27155 



PCT/US96/02303 



FIGURES 11A-11C show examples of functional 
relationship(s) between applications and the Rights Operating 
System; 

FIGURES 11D-11J show examples of "components" and 
"component assemblies"; 

FIGURE 12 is a more detailed diagram of an example of 
the Rights Operating System shown in FIGURE 10; 

FIGURE 12A shows an example of how "objects" can be 
created; 

FIGURE 13 is a detailed block diagram of an example the 
software architecture for a "protected processing environment" 
shown in FIGURE 12; 

FIGURES 14A-14C are examples of SPU memory maps 
provided by the protected processing environment shown in 
FIGURE 13; 
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FIGURE 15 illustrates an example of how the channel 
services manager and load module execution manager of 
FIGURE 13 can support a channel; 

5 FIGURE 15A is an example of a channel header and 

channel detail records shown in FIGURE 15; 

FIGURE 15B is a flowchart of an example of program 
control steps that may be performed by the FIGURE 13 protected 
10 processing environment to create a channel; 

FIGURE 16 is a block diagram of an example of a secure 
data base structure; 

15 FIGURE 17 is an illustration of an example of a logical 

object structure; 

FIGURE 18 shows an example of a stationary object 
structure; 



20 



FIGURE 19 shows an example of a traveling object 
structure; 
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FIGURE 20 shows an example of a content object 
structure; 

FIGURE 21 shows an example of an administrative object 
structure; 

FIGURE 22 shows an example of a method core structure; 
FIGURE 23 shows an example of a load module structure; 

FIGURE 24 shows an example of a User Data Element 
(UDE) and/or Method Data Element (MDE) structure; 

FIGURES 25A-25C show examples of "map meters"; 

FIGURE 26 shows an example of a permissions record 
(PERC) structure; 

FIGURES 26A and 26B together show a more detailed 
example of a permissions record structure; 
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FIGURE 27 shows an example of a shipping table 
structure; 

FIGURE 28 shows an example of a receiving table 
5 structure; 

FIGURE 29 shows an example of an administrative event 
log structure; 

10 FIGURE 30 shows an example inter-relationship between 

and use of the object registration table, subject table and user 
rights table shown in the FIGURE 16 secure database; 

FIGURE 31 is a more detailed example of an object 
15 registration table shown in FIGURE 16; 

FIGURE 32 is a more detailed example of subject table 
shown in FIGURE 16; 

20 FIGURE 33 is a more detailed example of a user rights 

table shown in FIGURE 16; 
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FIGURE 34 shows a specific example of how a site record 
table and group record table may track portions of the secure 
database shown in FIGURE 16; 

FIGURE 34A is an example of a FIGURE 34 site record 
table structure; 

FIGURE 34B is an example of a FIGURE 34 group record 
table structure; 

FIGURE 35 shows an example of a process for updating 
the secure database; 

FIGURE 36 shows an example of how new elements may 
be inserted into the FIGURE 16 secure data base; 

FIGURE 37 shows an example of how an element of the 
secure database may be accessed; 

FIGURE 38 is a flowchart example of how to protect a 
secure database element; 
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FIGURE 39 is a flowchart example of how to hack up a 
secure database; 

FIGURE 40 is a flowchart example of how to recover a 
5 secure database from a backup; 

FIGURES 41A-41D are a set of examples showing how a 
"chain of handling and control" may be enabled using "reciprocal 
methods"; 

10 

FIGURES 42A-42D show an example of a "reciprocal" 
BUDGET method; 

FIGURES 43A-43D show an example of a "reciprocal" 
15 REGISTER method; 

FIGURES 44A-44C show an example of a "reciprocal" 
AUDIT method; 

20 FIGURES 45-48 show examples of several methods being 

used together to control release of content or other information; 
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FIGURES 49, 49A-49F show an example OPEN method; 

FIGURES 50, 50A-50F show an example of a READ 
method; 

5 

FIGURES 51, 51A-51F show an example of a WRITE 
method; 

FIGURE 52 shows an example of a CLOSE method; 

10 

FIGURES 53A-53B show an example of an EVENT 
method; 

FIGURE 53C shows an example of a BILLING method; 

15 

FIGURE 54 shows an example of an ACCESS method; 

FIGURES 55A-55B show examples of DECRYPT and 
ENCRYPT methods; 

20 

FIGURE 56 shows an example of a CONTENT method; 
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FIGURES 57 A and 57B show examples of EXTRACT and 
EMBED methods; 

FIGURE 58A shows an example of an OBSCURE method; 

FIGURES 58B, 58C show examples of a FINGERPRINT 
method; 

FIGURE 59 shows an example of a DESTROY method; 

FIGURE 60 shows an example of a PANIC method; 

FIGURE 61 shows an example of a METER method; 

FIGURE 62 shows an example of a key "convolution" 
process; 

FIGURE 63 shows an example of how different keys may 
be generated using a key convolution process to determine a 
"true" key; 
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FIGURES 64 and 65 show an example of how protected 
processing environment keys may be initialized; 

FIGURES 66 and 67 show example processes for 
decrypting information contained within stationary and traveling 
objects, respectively; 

FIGURE 68 shows an example of how a protected 
processing environment may be initialized; 

FIGURE 69 shows an example of how firmware may be 
downloaded into a protected processing environment; 

FIGURE 70 shows an example of multiple VDE electronic 
appliances connected together with a network or other 
communications means; 

FIGURE 71 shows an example of a portable VDE electronic 
appliance; 



-153- 



WO 96/27155 



PCT/US96/02303 



FIGURES 72A-72D show examples of "pop-up" displays 
that may be generated by the user notification and exception 
interface; 

5 FIGURE 73 shows an example of a "smart object"; 

FIGURE 74 shows an example of a process using "smart 
objects"; 

10 FIGURES 75A-75D show examples of data structures used 

for electronic negotiation; ^ 

FIGURES 75E-75F show example structures relating to an 
electronic agreement; 

15 

FIGURES 76A-76B show examples of electronic 
negotiation processes; 

FIGURE 77 shows a further example of a chain of handling 
20 and control; 

FIGURE 78 shows an example of aVDE "repository"; 
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FIGURES 79-83 show an example illustrating a chain of 
handling and control to evolve and transform VDE managed 
content and control information; 

5 FIGURE 84 shows a further example of a chain of handling 

and control involving several categories of VDE participants; 

FIGURE 85 shows a further example of a chain of 
distribution and handling within an organization; 

10 

Figures 86 and 86A show a further example of a chain of 
handling and control; and 



Figure 87 shows an example of a virtual silicon container 
15 model. 
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MORE DETAI LED DESCRIPTION 

Figures 1-7 and the discussion below provides an overview 
of some aspects of features provided by this invention. Following 
this overview is a more technical "detail description" of example 
embodiments in accordance with the invention. 

Overview 

Figure 1 shows a 'Virtual Distribution Environment* 
("VDE") 100 that may be provided in accordance with this 
invention. In Figure 1, an information utility 200 connects to 
communications means 202 such as telephone or cable TV lines 
for example. Telephone or cable TV lines 202 may be part of an 
"electronic highway" that carries electronic information from 
place to place. Lines 202 connect information utility 200 to other 
people 
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such as for example a consumer 208, an office 210, a video 
production studio 204, and a publishing house 214. Each of the 
people connected to information utility 200 may be called a "VDE 
participant? because they can participate in transactions 
occurring within the virtual distribution environment 100. 

Almost any sort of transaction you can think of can be 
supported by virtual distribution environment 100. A few of 
many examples of transactions that can be supported by virtual 
distribution environment 100 include: 
C home banking and electronic payments; 
C electronic legal contracts; 

C distribution of "content" such as electronic printed matter, 
video, audio, images and computer programs; and 

C secure communication of private information such as 
medical records and financial information. 

Virtual distribution environment 100 is "virtual" because it 
does not require many of the physical "things" that used to be 
necessary to protect rights, ensure reliable and predictable 
distribution, and ensure proper compensation to content creators 
and distributors. For example, in the past, information was 
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distributed on records or disks that were difficult to copy. In the 
past, private or secret content was distributed in sealed 
envelopes or locked briefcases delivered by courier. To ensure 
appropriate compensation, consumers received goods and 
services only after they handed cash over to a seller. Although 
information utility 200 may deliver information by transferring 
physical "things" such as electronic storage media, the virtual 
distribution environment 100 facilitates a completely electronic 
"chain of handling and control." 

VDE Flexibility Supports Transactions 

Information utility 200 flexibly supports many different 
kinds of information transactions. Different VDE participants 
may define and/or participate in different parts of a transaction. 
Information utility 200 may assist with delivering information 
about a transaction, or it may be one of the transaction 
participants. 

For example, the video production studio 204 in the upper 
right-hand corner of Figure 1 may create video/television 
programs. Video production studio 204 may send these 
programs over lines 202, or may use other paths such as satellite 
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link 205 and CD ROM delivery service 216. Video production 
studio 204 can send the programs directly to consumers 206, 208, 
210, or it can send the programs to information utility 200 which 
may store and later send them to the consumers, for example. 
5 Consumers 206, 208, 210 are each capable of receiving and using 

the programs created by video production studio 204 — assuming, 
that is, that the video production studio or information utility 200 
has arranged for these consumers to have appropriate "mlesand 
controls " (control information) that give the consumers rights to 
10 use the programs. 

Even if a consumer has a copy of a video program, she 
cannot watch or copy the program unless she has "rules and 
controls" that authorize use of the program. She can use the 
15 program only as permitted by the "rules and controls." 



For example, video production studio 204 might release a 
half-hour exercise video in the hope that as many viewers as 
possible will view it. The video production studio 204 wishes to 
20 receive $2.00 per viewing. Video production studio 204 may, 

through information utility 200, make the exercise video 
available in "protected" form to all consumers 206, 208, 210. 
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Video production studio 204 may also provide "rules and controls" 
for the video. These "rules and controls" may specify for example: 

(1) any consumer who has good credit of at least $2.00 
5 based on a credit account with independent financial 

provider 212 (such as Mastercard or VISA) may watch the 
video, 

(2) virtual distribution environment 100 will "meter"' each 
10 time a consumer watches the video, and report usage to 

video production studio 204 from time to time, and 

(3) financial provider 212 may electronically collect 
payment ($2.00) from the credit account of each consumer 

15 who watches the video, and transfer these payments to the 

video production studio 204. 

Information utility 200 allows even a small video 
production studio to market videos to consumers and receive 
20 compensation for its efforts. Moreover, the videos can, with 

appropriate payment to the video production studio, be made 
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available to other video publishers who may add value and/or act 
as repackagers or redistributors. 

Figure 1 also shows a publishing house 214. Publishing 
house 214 may act as a distributor for an author 206. The 
publishing house 214 may djgfejbute rights to use "content" (such 
as computer software, electronic newspapers, the video produced 
by publishing house 214, audio, or any other data) to consumers 
such as office 210. The use rights may be defined by "rules and 
controls" distributed by publishing house 216. Publishing house 
216 may distribute these "rules and controls" with the content, 
but this is not necessary. Because the content can be used only 
by consumers that have the appropriate "rules and controls," 
content and its associated "rules and controls" may be distributed 
at different times, in different ways, by different VDE 
participants. The ability of VDE to securely distribute and 
enforce "rules and controls" separately from the content they 
apply to provides great advantages. 

Use rights distributed by publishing house 214 may, for 
example, permit office 210 to make and distribute copies of the 
content to its employees. Office 210 may act as a redistributor by 
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extending a "chain of handling and control" to its employees. The 
office 210 may add or modify "rules and controls" (consistent with 
the "rules and controls" it receives from publishing house 214) to 
provide office-internal control information and mechanisms. For 
example, office 210 may set a maximum usage budget for each 
individual user and/or group within the office, or it may permit 
only specified employees and/or groups to access certain 
information. 

Figure 1 also shows an information delivery service 216 
delivering electronic storage media such as "CD ROM" disks to 
consumers 206. Even though the electronic storage media 
themselves are not delivered electronically by information utility 
200 over lines 202, they are still part of the virtual distribution 
environment 100. The electronic storage media may be used to 
distribute content, "rules and controls," or other information. 

Example of What's Inside Information Utility 200 

"Information utility" 200 in Figure 1 can be a collection of 
participants that may act as distributors, financial 
clearinghouses, and administrators. Figure 1A shows an 
example of what may be inside one example of information utility 
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200. Information utility participants 200a-200g could each be an 
independent organization/business. There can be any number of 
each of participants 200a-200g. In this example, electronic 
"switch" 200a connects internal parts of information utility 200 to 
each other and to outside participants, and may also connect 
outside participants to one another. 

Information utility 200 may include a "transaction 
processor" 200b that processes transactions (to transfer 
electronic funds, for example) based on requests from 
participants and/or report receiver 200e. It may also include a 
"usage analyst" 200c that analyzes reported usage information. 
A "report creator" 200d may create reports based on usage for 
example, and may provide these reports to outside participants 
and/or to participants within information utility 200. A "report 
receiver" 200e may receive reports such as usage reports from 
content users. A "permissioning agent" 200f may distribute 
"rules and controls" granting usage or distribution permissions 
based on a profile of a consumer's credit worthiness, for example. 
An administrator 200h may provide information that keeps the 
virtual distribution environment 100 operating properly. A 
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content and message storage 200g may store information for use 
by participants within or outside of information utility 200. 

Example of Distributing Content" Using A Chain of Handling 
and Control" 

As explained above, virtual distribution environment 100 
can be used to manage almost any sort of transaction. One type 
of important transaction that virtual distribution environment 
100 may be used to manage is the distribution or communication 
of "content" or other important information. Figure 2 more 
abstractly shows a "model" of how the Figure 1 virtual 
distribution environment 100 may be used to provide a "chain of 
handling and control" for distributing content. Each of the blocks 
in Figure 2 may correspond to one or more of the VDE 
participants shown in Figure 1. 

In the Figure 2 example, a VDE content creator 102 
creates "content ." The content creator 102 may also specify 
"rules and controls" for distributing the content. These 
distribution-related "rules and controls" can specify who has 
permission to distribute the rights to use content, and how many 
users are allowed to use the content. 
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Arrow 104 shows the content creator 102 sending the 
"rules and controls" associated with the content to a VDE rights 
distrilmtflr 106 ("distributor") over an electronic highway 108 (or 
by some other path such as an optical disk sent by a delivery 
5 service such as U. S. mail). The content can be distributed over 

the same or different path used to send the "rules and controls." 
The distributor 106 generates her own "rules and controls" that 
relate to usag e of the content. The usage-related "rules and 
controls" may, for example, specify what a user can and can't do 
10 with the content and how much it costs to use the content. These 

usage-related "rules and controls" must be consistent with the 
"rules and controls" specified by content creator 102. 



Arrow 110 shows the distributor 106 distributing rights to 
15 use the content by sending the content's "rules and controls" to a 

content user 112 such as a consumer. The content user 112 uses 
the content in accordance with the usage-related "rules and 
controls." 

20 In this Figure 2 example, information relating to content 

use is, as shown by arrow 114, reported to a financial 
rlftflrm ghnnse 116. Based on this "reporting," the financial 
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clearinghouse 116 may generate a biU and send it to the content 
user 112 over a "reports and payments" network 118. Arrow 120 
shows the content user 112 providing payments for content usage 
to the financial clearinghouse 116. Based on the reports and 
payments it receives, the financial clearinghouse 116 may 
provide reports and/or payments to the distributor 106. The 
distributor 106 may, as shown by arrow 122, provide reports 
and/or payments to the content creator 102. The clearinghouse 
116 may provide reports and payments directly to the creator 
102. Reporting and/or payments may be done differently. For 
example, clearinghouse 116 may directly or through an agent, 
provide reports and/or payments to each of VDE content creators 
102, and rights distributor 106, as well as reports to content user 
112. 



The distributor 106 and the content creator 102 may be the 
same person, or they may be different people. For example, a 
musical performing group may act as both content creator 102 
and distributor 106 by creating and distributing its own musical 
recordings. As another example, a publishing house may act as a 
distributor 106 to distribute rights to use works created by an 
author content creator 102. Content creators 102 may use a 
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distributor 106 to efficiently manage the financial end of content 
distribution. 

The "financial clearinghouse" 116 shown in Figure 2 may 
5 also be a "YTTE admini strator .* Financial clearinghouse 1 16 in its 

VDE administrator role sends "administrative" information to 
the VDE participants. This administrative information helps to 
keep the virtual distribution environment 100 operating 
properly. The "VDE administrator 7 ' and financial clearinghouse 
10 roles may be performed by different people or companies, and 

there can be more than one of each. 

More about Rules and Controls* 

The virtual distribution environment 100 prevents use of 
15 protected information except as permitted by the "rules and 

controls" (control information). For example, the "rules and 
controls" shown in Figure 2 may grant specific individuals or 
classes of content users 112 "permission" to use certain content. 
They may specify what kinds of content usage are permitted, and 
20 what kinds are not. They may specify how content usage is to be 

paid for and how much it costs. As another example, "rules and 
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controls" may require content usage information to be reported 
back to the distributor 106 and/or content creator 102. 

Every VDE participant in "chain of handling and control" 
5 is normally subject to "rules and controls." "Rules and controls" 

define the respective rights and obligations of each of the various 
VDE participants. "Rules and controls" provide information and 
mechanisms that may establish interdependencies and 
relationships between the participants. "Rules and controls" are 
10 flexible, and permit "virtual distribution environment* 100 to 

support most "traditional" business transactions. For example: 
C "Rules and controls" may specify which financial 

clearinghouse(s) 116 may process payments, 
C "Rules and controls" may specify which participant(s) 
15 receive what kind of usage report, and 

C "Rules and controls" may specify that certain information 

is revealed to certain participants, and that other 

information is kept secret from them. 

20 "Rules and controls" may self limit if and how they may be 

changed. Often, "rules and controls" specified by one VDE 
participant cannot be changed by another VDE participant. For 
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example, a content user 112 generally can't change "rules and 
controls 9 specified by a distributor 106 that require the user to 
pay for content usage at a certain rate. "Rules and controls" may 
"persist" as they pass through a "chain of handling and control," 
and may be "inherited" as they are passed down from one VDE 
participant to the next. 

Depending upon their needs, VDE participants can specify 
that their "rules and controls" can be changed under conditions 
specified by the same or other "rules and controls." For example, 
"rules and controls" specified by the content creator 102 may 
permit the distributor 106 to "mark up" the usage price just as 
retail stores "mark up" the wholesale price of goods. Figure 2A 
shows an example in which certain "rules and controls" persist 
unchanged from content creator 102 to content user 112; other 
"rules and controls" are modified or deleted by distributor 106; 
and still other "rules and controls" are added by the distributor. 

"Rules and controls" can be used to protect the content 
user's privacy by limiting the information that is reported to 
other VDE participants. As one example, "rules and controls" 
can cause content usage information to be reported anonymously 
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without reve aling content user identity, or it can reveal only 
certain information to certain participants (for example, 
information derived from usage) with appropriate permission, if 
required. This ability to securely control what information is 
revealed and what VDE participant(s) it is revealed to allows the 
privacy rights of all VDE participants to be protected 

Rules and Contents 9 Can Be Separately Delivered 

As mentioned above, virtual distribution environment 100 
"associates" content with corresponding "rules and controls," and 
prevents the content from being used or accessed unless a set of 
corresponding "rules and controls" is available. The distributor 
106 doesn't need to deliver content to control the content's 
distribution. The preferred embodiment can securely protect 
content by protecting corresponding, usage enabling "rules and 
controls" against unauthorized distribution and use. 

In some examples, "rules and controls" may travel with the 
content they apply to. Virtual distribution environment 100 also 
allows "rules and controls" to be delivered separately from 
content. Since no one can use or access protected content 
without "permission" from corresponding "rules and controls," the 
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10 



distributor 106 can control use of content that has already been 
(or will in the future be) delivered. "Rules and controls" may be 
delivered over a path different from the one used for content 
delivery. M Rules and controls" may also be delivered at some 
other time. The content creator 102 might deliver content to 
content user 112 over the electronic highway 108, or could make 
the content available to anyone on the highway. Content may be 
used at the time it is delivered, or it may be stored for later use or 
reuse. 



The virtual distribution environment 100 also allows 
payment and reporting means to be delivered separately. For 
example, the content user 112 may have a virtual "credit card" 
that extends credit (up to a certain limit) to pay for usage of any 
15 content. Accredit transaction" can take place at the user's site 

without requiring any "online" connection or further 
authorization. This invention can be used to help securely 
protect the virtual "credit card" against unauthorized use. 

20 Rules and Contents* Define Processes 

Figure 3 shows an example of an overall process based on 
"rules and controls " It includes an "events" process 402, a meter 
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process 404, a billing process 406, and a budget process 408. Not 
all of the processes shown in Figure 3 will be used for every set of 
"rules and controls." 

5 The "events process" 402 detects things that happen 

("events") and determines which of those "events" need action by 
the other "processes ." The "events" may include, for example, a 
request to use content or generate a usage permission. Some 
events may need additional processing, and others may not. 

10 Whether an "event" needs more processing depends on the "rules 

and controls" corresponding to the content. For example, a user 
who lacks permission will not have her request satisfied ("No 
Go"). As another example, each user request to turn to a new 
page of an electronic book may be satisfied ("Go"), but it may not 

15 be necessary to meter, bill or budget those requests. A user who 

has purchased a copy of a novel may be permitted to open and 
read the novel as many times as she wants to without any 
further metering, b illing or budgeting. In this simple example, 
the "event process" 402 may request metering, billing and/or 

20 budgeting processes the first time the user asks to open the 

protected novel (so the purchase price can be charged to the 
user), and treat all later requests to open the same novel as 
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"insignificant events." Other content (for example, searching an 
electronic telephone directory) may require the user to pay a fee 
for each access. 



5 "Meter* process 404 keeps track of events, and may report 

usage to distributor 106 and/or other appropriate VDE 
participant(s). Figure 4 shows that process 404 can be based on a 
number of different factors such as: 
(a) type of usage to charge for, 
10 (b) what kind of unit to base charges on, 

(c) how much to charge per unit, 

(d) when to report, and 

(e) how to pay. 

These factors may be specified by the "rules and controls'' that 
15 control the meter process. 



Billing process 406 determines how much to charge for 
events. It records and reports payment information. 

20 Budget process 408 limits how much content usage is 

permitted. For example, budget process 408 may limit the 
number of times content may be accessed or copied, or it may 
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limit the number of pages or other amount of content that can be 
used based on, for example, the number of dollars available in a 
credit account. Budget process 408 records and reports financial 
and other transaction information associated with such limits. 

Content may be supplied to the user once these processes 
have been successfully performed. 

Containers and Objects* 

Figure 5A shows how the virtual distribution environment 
100, in a preferred embodiment, may package information 
elements (content) into a "container* 302 so the information can't 
be accessed except as provided by its "rules and controls" 
Normally, the container 302 is electronic rather than physical. 
Electronic container 302 in one example comprises "digital" 
information having a well defined structure. Container 302 and 
its contents can be called an "object 300." 

The Figure 5A example shows items "within" and enclosed 
by container 302. However, container 302 may "contain" items 
without those items actually being stored within the container. 
For example, the container 302 may reference items that are 
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available elsewhere such as in other containers at remote sites. 
Container 302 may reference items available at different times or 
only during limited times. Some items may be too large to store 
within container 302. Items may, for example, be delivered to the 
user in the form of a "live feed" of video at a certain time. Even 
then, the container 302 "contains* the live feed (by reference) in 
this example. 

Container 302 may contain information content 304 in 
electronic (such as "digital") form. Information content 304 could 
be the text of a novel, a picture, sound such as a musical 
performance or a reading, a movie or other video, computer 
software, or just about any other kind of electronic information 
you can think of. Other types of "objects" 300 (such as 
"administrative objects") may contain "administrative" or other 
information instead of or in addition to information content 304. 

In the Figure 5A example, container 302 may also contain 
"rules and controls" in the form of: 

(a) a "permissio ns record" 808: 

(b) "budgets" 308; and 

(c) "other methods" 1000. 
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Figure 5B gives some additional detail about permissions 
record 808, budgets 308 and other methods 1000. The 
"permissions record* 808 specifies the rights associated with the 
object 300 such as, for example, who can open the container 302, 
5 who can use the object's contents, who can distribute the object, 

and what other control mechanisms must be active. For example, 
permissions record 808 may specify a user's rights to use, 
distribute and/or administer the container 302 and its content. 
Permissions record 808 may also specify requirements to be 
10 applied by the budgets 308 and "other methods* 1000. 

Permissions record 808 may also contain security related 
information such as scrambling and descrambling "keys." 

"Budgets" 308 shown in Figure 5B are a special type of 
15 "method* 1000 that may specify, among other things, limitations 

on usage of information content 304, and how usage will be paid 
for. Budgets 308 can specify, for example, how much of the total 
information content 304 can be used and/or copied. The methods 
310 may prevent use of more than the amount specified by a 
20 specific budget. 
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"Other methods" 1000 define basic operations used by 
"rules and controls." Such "methods" 1000 may include, for 
example, how usage is to be "metered," if and how content 304 
and other information is to be scrambled and descrambled, and 
other processes associated with handling and controlling 
information content 304. For example, methods 1000 may record 
the identity of anyone who opens the electronic container 302, 
and can also control how information content is to be charged 
based on "metering." Methods 1000 may apply to one or several 
different information contents 304 and associated containers 302, 
as well as to all or specific portions of information content 304. 

Secure Processing Unit (SPU) 

The "VDE participants" may each have an "electronic 
a ppliance ." The appliance may be or contain a computer. The 
appliances may communicate over the electronic highway 108. 
Figure 6 shows a secure procPRsiTig unit ("SPU") 500 portion of 
the "electronic appliance" used in this example by each VDE 
participant. SPU 500 processes information in a secure 
processing environment 503, and stores important information 
securely. SPU 500 may be emulated by software operating in a 
host electronic appliance. 
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SPU 500 is enclosed within and protected by a "tamper 
resistant security barrier" 502. Security barrier 502 separates 
the secure environment 503 from the rest of the world. It 
prevents information and processes within the secure 
environment 503 from being observed, interfered with and 
leaving except under appropriate secure conditions. Barrier 502 
also controls external access to secure resources, processes and 
information within SPU 500. Li one example, tamper resistant 
security barrier 502 is formed by security features such as 
Encryption/' and hardware that detects tampering and/or 
destroys sensitive information within secure environment 503 
when tampering is detected. 

SPU 500 in this example is an integrated circuit ("IC") 
"chip" 504 including "hardware* 506 and "firmware" 508. SPU 
500 connects to the rest of the electronic appliance through an 
«iipp1ifmpft liTiysm SPU "firmware" 508 in this example is 
"software" such as a "computer program(s)" "embedded" within 
chip 504. Firmware 508 makes the hardware 506 work. 
Hardware 506 preferably contains a processor to perform 
instructions specified by firmware 508. "Hardware" 506 also 
contains long-term and short-term memories to store information 
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securely so it can't be tampered with. SPU 500 may also have a 
protected clock/calendar used for timing events. The SPU 
hardware 506 in this example may include special purpose 
electronic circuits that are specially designed to perform certain 
processes (such as "encryption" and "decryption") rapidly and 
efficiently* 

The particular context in which SPU 500 is being used will 
determine how much processing capabilities SPU 500 should 
have. SPU hardware 506, in this example, provides at least 
enough processing capabilities to support the secure parts of 
processes shown in Figure 3. In some contexts, the functions of 
SPU 500 may be increased so the SPU can perform all the 
electronic appliance processing, and can be incorporated into a 
general purpose processor. In other contexts, SPU 500 may work 
alongside a general purpose processor, and therefore only needs 
to have enough processing capabilities to handle secure 
processes. 
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VDE Electronic Appliance and Rights Operating System" 

Figure 7 shows an example of an electronic appliance 600 
inclu ding SPU 500, Electronic appliance 600 may be practically 
any kind of electrical or electronic device, such as: 

5 



c 


a computer 


c 


a T.V. "set top" control box 


c 


a pager 


c 


a telephone 


c 


a sound system 


c 


a video reproduction system 


c 


a video game player 


c 


a "smart" credit card 



15 Electronic appliance 600 in this example may include a keyboard 

or keypad 612, a voice recognizer 613, and a display 614. A 
human user can input commands through keyboard 612 and/or 
voice recognizer 613, and may view information on display 614. 
Appliance 600 may co mmunic ate with the outside world through 

20 any of the connections/devices normally used within an electronic 

appliance. The connections/devices shown along the bottom of 
the drawing are examples: 
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a "modem" 618 or other telecommunications link; 
a CD ROM disk 620 or other storage medium or device; 
a printer 622; 
broadcast reception 624; 
5 a document scanner 626; and 

a "cable" 628 connecting the appliance with a "network." 



Virtual distribution environment 100 provides a "rights 
operating system" 602 that manages appliance 600 and SPU 500 

10 by controlling their hardware resources. The operating system 

602 may also support at least one "a pplication" 608. Generally, 
"application" 608 is hardware and/or software specific to the 
context of appliance 600. For example, if appliance 600 is a 
personal computer, then "application" 608 could be a program 

15 loaded by the user, for instance, a word processor, a 

communications system or a sound recorder. If appliance 600 is a 
television controller box, then application 608 might be hardware 
or software that allows a user to order videos on demand and 
perform other functions such as fast forward and rewind. In this 

20 example, operating system 602 provides a standardized, well 

defined, generalized "interface" that could support and work 
with many different "applications" 608. 
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Operating system 602 in this example provides "rights and 
auditing operating system functions" 604 and "other operating 
system functions" 606. The "rights and auditing operating 
system functions" 604 securely handle tasks that relate to virtual 
distribution environment 100. SPU 500 provides or supports 
many of the security functions of the "rights and auditing 
operating system functions" 402. The "other operating system 
functions" 606 handle general appliance functions. Overall 
operating system 602 may be designed from the beginning to 
include the "rights and auditing operating system functions" 604 
plus the "other operating system functions" 606, or the "rights 
and auditing operating system functions" may be an add-on to a 
preexisting operating system providing the "other operating 
system functions." 

"Rights operating system" 602 in this example can work 
with many different types of appliances 600. For example, it can 
work with large mainframe computers, "minicomputers" and 
"microcomputers" such as personal computers and portable 
computing devices. It can also work in control boxes on the top of 
television sets, small portable "pagers," desktop radios, stereo 
sound systems, telephones, telephone switches, or any other 
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electronic appliance. This ability to work on big appliances as 
well as little appliances is called "scalable." A "scalable* 
operating system 602 means that there can be a standardized 
interface across many different appliances performing a wide 
variety of tasks. 

The "rights operating system functions" 604 are "services- 
based" in this example. For example, "rights operating system 
functions" 604 handle summary requests from application 608 
rather than requiring the application to always make more 
detailed "subrequests" or otherwise get involved with the 
underlying complexities involved in satisfying a summary 
request. For example, application 608 may simply ask to read 
specified information; "rights operating system functions" 604 
can then decide whether the desired information is VDE- 
protected content and, if it is, perform processes needed to make 
the information available. This feature is called "transparency." 
"Transparency" makes tasks easy for the application 608. 
"Rights operating system functions" 604 can support applications 
608 that "know" nothing about virtual distribution environment 
100. Applications 608 that are "aware" of virtual distribution 
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environment 100 may be able to make more detailed use of 
virtual distribution environment 100. 

In this example, "rights operating system functions" 604 
are "event driven". Rather than repeatedly examining the state 
of electronic appliance 600 to determine whether a condition has 
arisen, the "rights operating system functions" 604 may respond 
directly to "events" or "happenings" within appliance 600. 

In this example, some of the services performed by "rights 
operating system functions" 604 may be extended based on 
additional "components" delivered to operating system 602. 
"Rights operating system functions" 604 can collect together and 
use "components" sent by different participants at different 
times. The "components" help to make the operating system 602 
"scalable." Some components can change how services work on 
little appliances versus how they work on big appliances (e.g., 
multi-user). Other components are designed to work with specific 
applications or classes of applications (e.g., some types of meters 
and some types of budgets). 

Electronic Appliance 600 
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An electronic appliance 600 provided by the preferred 
embodiment may, for example, be any electronic apparatus that 
contains one or more microprocessors and/or microcontrollers 
and/or other devices which perform logical and/or mathematical 
calculations. This may include computers; computer terminals; 
device controllers for use with computers; peripheral devices for 
use with computers; digital display devices; televisions; video and 
audio/video projection systems; channel selectors and/or decoders 
for use with broadcast and/or cable transmissions; remote control 
devices; video and/or audio recorders; media players including 
compact disc players, videodisc players and tape players; audio 
and/or video amplifiers; virtual reality machines; electronic game 
players; multimedia players; radios; telephones; videophones; 
facsimile machines; robots; numerically controlled machines 
including machine tools and the like; and other devices 
containing one or more microcomputers and/or microcontrollers 
and/or other CPUs, including those not yet in existence. 

Figure 8 shows an example of an electronic appliance 600. 
This example of electronic appliance 600 includes a system bus 
653. In this example, one or more conventional general purpose 
central processing units ("CPUs") 654 are connected to bus 653. 
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Bus 653 connects CPU(s) 654 to RAM 656, ROM 658, and I/O 
controller 660. One or more SPUs 500 may also be connected to 
system bus 653. System bus 653 may permit SPU(s) 500 to 
communicate with CPU(s) 654, and also may allow both the 
CPU(s) and the SPU(s) to communicate (e.g., over shared address 
and data lines) with RAM 656, ROM 658 and I/O controller 660. 
A power supply 659 may provide power to SPU 500, CPU 654 and 
the other system components shown. 

In the example shown, I/O controller 660 is connected to 
secondary storage device 652, a keyboard/display 612,614, a 
communications controller 666, and a backup storage device 668. 
Backup storage device 668 may, for example, store information 
on mass media such as a tape 670, a floppy disk, a removable 
memory card, etc. Co mmunic ations controller 666 may allow 
electronic appliance 600 to communicate with other electronic 
appliances via network 672 or other telecommunications links. 
Different electronic appliances 600 may interoperate even if they 
use different CPUs and different instances of ROS 602, so long as 
they typically use compatible communication protocols and/or 
security methods. In this example, I/O controller 660 permits 
CPU 654 and SPU 500 to read from and write to secondary 
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storage 662, keyboard/display 612, 614, communications 
controller 666, and backup storage device 668. 

Secondary storage 662 may comprise the same one or 
more non-secure secondary storage devices (such as a magnetic 
disk and a CD-ROM drive as one example) that electronic 
appliance 600 uses for general secondary storage functions. In 
some implementations, part or all of secondary storage 652 may 
comprise a secondary storage device(s) that is physically enclosed 
within a secure enclosure. However, since it may not be practical 
or cost-effective to physically secure secondary storage 652 in 
many implementations, secondary storage 652 may be used to 
store information in a secure manner by encrypting information 
before storing it in secondary storage 652. If information is 
encrypted before it is stored, physical access to secondary storage 
652 or its contents does not readily reveal or compromise the 
information. 

Secondary storage 652 in this example stores code and 
data used by CPU 654 and/or SPU 500 to control the overall 
operation of electronic appliance 600. For example, Figure 8 
shows that "Rights Operating System" ("ROS") 602 (including a 
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portion 604 of ROS that provides VDE functions and a portion 
606 that provides other OS functions) shown in Figure 7 may be 
stored on secondary storage 652. Secondary storage 652 may 
also store one or more VDE objects 300. Figure 8 also shows that 
5 the secure files 610 shown in Figure 7 may be stored on 

secondary storage 652 in the form of a "secure database" or 
management file system 610. This secure database 610 may 
store and organize information used by ROS 602 to perform VDE 
functions 604. Thus, the code that is executed to perform VDE 
10 and other OS functions 604, 606, and secure files 610 (as well as 

VDE objects 300) associated with those functions may be stored 
in secondary storage 652. Secondary storage 652 may also store 
"other information" 673 such as, for example, information used by 
other operating system functions 606 for task management, non- 
15 VDE files, etc. Portions of the elements indicated in secondary 
storage 652 may also be stored in ROM 658, so long as those 
elements do not require changes (except when ROM 658 is 
replaced). Portions of ROS 602 in particular may desirably be 
included in ROM 658 (e.g., "bootstrap" routines, POST routines, 
20 etc. for use in estab lishing an operating environment for 
electronic appliance 600 when power is applied). 
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Figure 8 shows that secondary storage 652 may also be 
used to store code ("application programs") providing user 
application^) 608 shown in Figure 7. Figure 8 shows that there 
may be two general types of application programs 608: "VDE 
aware" applications 608a, and Non-VDE aware applications 
608b. VDE aware applications 608a may have been at least in 
part designed specifically with VDE 100 in mind to access and 
take detailed advantage of VDE functions 604. Because of the 
"transparency" features of ROS 602, non-VDE aware applications 
608b (e.g., applications not specifically designed for VDE 100) 
can also access and take advantage of VDE functions 604. 

SECURE PROCESSING UNIT 500 

Each VDE node or other electronic appliance 600 in the 
preferred embodiment may include one or more SPUs 500. SPUs 
500 may be used to perform all secure processing for VDE 100. 
For example, SPU 500 is used for decrypting (or otherwise 
unsecuring) VDE protected objects 300. It is also used for 
managing encrypted and/or otherwise secured communication 
(such as by employing authentication and/or error-correction 
validation of information). SPU 500 may also perform secure 
data management processes including governing usage of, 
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auditing of, and where appropriate, payment for VDE objects 300 
(through the vise of prepayments, credits, real-time electronic 
debits from bank accounts and/or VDE node currency token 
deposit accounts). SPU 500 may perform other transactions 
related to such VDE objects 300. 

SPU Physical Packaging and Security Barrier 502 

As shown Figure 6, in the preferred embodiment, an SPU 
500 may be implemented as a single integrated circuit "chip" 505 
to provide a secure processing environment in which confidential 
and/or commercially valuable information can be safely 
processed, encrypted and/or decrypted. IC chip 505 may, for 
example, comprise a small semiconductor "die" about the size of a 
thumbnail. This semiconductor die may include semiconductor 
and metal conductive pathways. These pathways define the 
circuitry, and thus the functionality, of SPU 500. Some of these 
pathways are electrically connected to the external "pins" 504 of 
the chip 505. 

As shown in Figures 6 and 9, SPU 500 may be surrounded 
by a tamper-resistant hardware security barrier 502. Part of this 
security barrier 502 is formed by a plastic or other package in 
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which an SPU "die" is encased. Because the processing occurring 
within, and information stored by, SPU 500 are not easily 
accessible to the outside world, they are relatively secure from 
unauthorized access and tampering. All signals cross barrier 502 
through a secure, controlled path provided by BIU 530 that 
restricts the outside world's access to the internal components 
within SPU 500. This secure, controlled path resists attempts 
from the outside world to access secret information and resources 
within SPU 500. 

It is possible to remove the plastic package of an IC chip 
and gain access to the "die." It is also possible to analyze and 
"reverse engineer" the "die" itself (e.g., using various types of 
logic analyzers and microprobes to collect and analyze signals on 
the die while the circuitry is operating, using acid etching or 
other techniques to remove semiconductor layers to expose other 
layers, viewing and photographing the die using an electron 
microscope, etc.) Although no system or circuit is absolutely 
. impervious to such attacks, SPU barrier 502 may include - - 
additional hardware protections that make successful attacks 
exceedingly costly and time consuming. For example, ion 
implantation and/or other fabrication techniques may be used to 
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make it very difficult to visually discern SPU die conductive 
pathways, and SPU internal circuitry may be fabricated in such a 
way that it "self-destructs" when exposed to air and/or light. SPU 
500 may store secret information in internal memory that loses 
its contents when power is lost. Circuitry may be incorporated 
within SPU 500 that detects microprobing or other tampering, 
and self-destructs (or destroys other parts of the SPU) when 
tampering is detected. These and other hardware-based physical 
security techniques contribute to tamper-resistant hardware 
security barrier 502. 

To increase the security of security barrier 502 even 
further, it is possible to encase or include SPU 500 in one or more 
further physical enclosures such as, for example: epoxy or other 
"potting compound"; further module enclosures including 
additional self-destruct, self-disabling or other features activated 
when tampering is detected; further modules providing 
additional security protections such as requiring password or 
other authentication to operate; and the like. In addition, further 
layers of metal may be added to the die to complicate acid 
etching, micro probing, and the like; circuitry designed to 
"zeroize" memory may be included as an aspect of self-destruct 
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processes; the plastic package itself may be designed to resist 
chemical as well as physical "attacks"; and memories internal to 
SPU 500 may have specialized addressing and refresh circuitry 
that "shuffles" the location of bits to complicate efforts to 
electrically determine the value of memory locations. These and 
other techniques may contribute to the security of barrier 502. 

In some electronic appliances 600, SPU 500 may be 
integrated together with the device microcontroller or equivalent 
or with a device I/O or communications microcontroller into a 
common chip (or chip set) 505. For example, in one preferred 
embodiment, SPU 500 may be integrated together with one or 
more other CPU(s) (e.g., a CPU 654 of an electronic appliance) in 
a single component or package. The other CPU(s) 654 may be 
any centrally controlling logic arrangement, such as for example, 
a microprocessor, other microcontroller, and/or array or other 
parallel processor. This integrated configuration may result in 
lower overall cost, smaller overall size, and potentially faster 
interaction between an SPU 500 and a CPU 654. Integration 
may also provide wider distribution if an integrated SPU/CPU 
component is a standard feature of a widely distributed 
microprocessor line. Merging an SPU 500 into a main CPU 654 
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of an electronic appliance 600 (or into another appliance or 
appliance peripheral microcomputer or other microcontroller) 
may substantially reduce the overhead cost of implementing VDE 
100. Integration considerations may include cost of 
implementation, cost of manufacture, desired degree of security, 
and value of compactness. 

SPU 500 may also be integrated with devices other than 
CPUs. For example, for video and multimedia applications, some 
performance and/or security advantages (depending on overall 
design) could result from integrating an SPU 500 into a video 
controller chip or chipset. SPU 500 can also be integrated 
directly into a network communications chip or chipset or the 
like. Certain performance advantages in high speed 
communications applications may also result from integrating an 
SPU 500 with a modem chip or chipset. This may facilitate 
incorporation of an SPU 500 into communication appliances such 
as stand-alone fax machines. SPU 500 may also be integrated 
into other peripheral devices, such as CD-ROM devices, set-top 
cable devices, game devices, and a wide variety of other electronic 
appliances that use, allow access to, perform transactions related 
to, or consume, distributed information. 
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SPU 500 Internal Architecture 

Figure 9 is a detailed diagram of the internal structure 
within an example of SPU 500. SPU 500 in this example 
includes a single microprocessor 520 and a limited amount of 
memory configured as ROM 532 and RAM 534. In more detail, 
this example of SPU 500 includes microprocessor 520, an 
encrypt/decrypt engine 522, a DMA controller 526, a real-time 
clock 528, a bus interface unit ("BIU") 530, a read only memory 
(ROM) 532, a random access memory (RAM) 534, and a memory 
management unit ("MMU") 540. DMA controller 526 and MMU 
540 are optional, but the performance of SPU 500 may suffer if 
they are not present. SPU 500 may also include an optional 
pattern matching engine 524, an optional random number 
generator 542, an optional arithmetic accelerator circuit 544, and 
optional compression/decompression circuit 546. A shared 
address/data bus arrangement 536 may transfer information 
between these various components under control of 
microprocessor 520 and/or DMA controller 526. Additional or 
alternate dedicated paths 538 may connect microprocessor 520 to 
the other components (e.g., encrypt/decrypt engine 522 via line 
538a, real-time clock 528 via line 538b, bus interface unit 530 via 
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line 538c, DMA controller via line 538d, and memory 
management unit (MMU) 540 via line 538e). 

The following section discusses each of these SPU 
components in more detail. 

Microprocessor 520 

Microprocessor 520 is the "brain" of SPU 500. In this 
example, it executes a sequence of steps specified by code stored 
(at least temporarily) within ROM 532 and/or RAM 534. 
Microprocessor 520 in the preferred embodiment comprises a 
dedicated central processing arrangement (e.g., a RISC and/or 
CISC processor unit, a microcontroller, and/or other central 
processing means or, less desirably in most applications, process 
specific dedicated control logic) for executing instructions stored 
in the ROM 532 and/or other memory. Microprocessor 520 may 
be separate elements of a circuitry layout, or may be separate 
packages within a secure SPU 500. 

In the preferred embodiment, microprocessor 520 normally 
handles the most security sensitive aspects of the operation of 
electronic appliance 600. For example, microprocessor 520 may 



-196- 



WO 96/27155 



PCT/US96/02303 



manage VDE decrypting, encrypting, certain content and/or 
appliance usage control information, keeping track of usage of 
VDE secured content, and other VDE usage control related 
functions. 

Stored in each SPU 500 and/or electronic appliance 
secondary memory 652 may be, for example, an instance of ROS 
602 software, application programs 608, objects 300 containing 
VDE controlled property content and related information, and 
management database 610 that stores both information 
associated with objects and VDE control information. ROS 602 
includes software intended for execution by SPU microprocessor 
520 for, in part, controlling usage of VDE related objects 300 by 
electronic appliance 600. As will be explained, these SPU 
programs include "load modules" for performing basic control 
functions. These various programs and associated data are 
executed and manipulated primarily by microprocessor 520. 

Real Time Clock (ETC) 628 

In the preferred embodiment, SPU 500 includes a real time 
clock circuit ("RTC") 528 that serves as a reliable, tamper 
resistant time base for the SPU. RTC 528 keeps track of time of 
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day and date (e.g., month, day and year) in the preferred 
embodiment, and thus may comprise a combination calendar and 
clock. A reliable time base is important for implementing time 
based usage metering methods, "time aged decryption keys," and 
5 other time based SPU functions. 

The RTC 528 must receive power in order to operate. 
Optimally, the RTC 528 power source could comprise a small 
battery located within SPU 500 or other secure enclosure. 

10 However, the RTC 528 may employ a power source such as an 

externally located battery that is external to the SPU 500. Such 
an externally located battery may provide relatively 
uninterrupted power to RTC 528, and may also maintain as 
non-volatile at least a portion of the otherwise volatile RAM 534 

15 within SPU 500. 

In one implementation, electronic appliance power supply 
659 is also used to power SPU 500. Using any external power 
supply as the only power source for RTC 528 may significantly 
20 reduce the usefulness of time based security techniques unless, at 

TniTuirmrr^ SPU 500 recognizes any interruption (or any material 
interruption) of the supply of external power, records such 
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interruption, and responds as may be appropriate such as 
disabling the ability of the SPU 500 to perform certain or all VDE 
processes. Recognizing a power interruption may, for example, 
be accomplished by employing a circuit which is activated by 
power failure. The power failure sensing circuit may power 
another circuit that includes associated logic for recording one or 
more power fail events. Capacitor discharge circuitry may 
provide the necessary temporary power to operate this logic. In 
addition or alternatively, SPU 500 may from time to time 
compare an output of RTC 528 to a clock output of a host 
electronic appliance 600, if available. In the event a discrepancy 
is detected, SPU 500 may respond as appropriate, including 
recording the discrepancy and/or disabling at least some portion 
of processes performed by SPU 500 under at least some 
circumstances. 

If a power failure and/or RTC 528 discrepancy and/or other 
event indicates the possibility of tampering, SPU 500 may 
automatically destroy, or render inaccessible without privileged 
intervention, one or more portions of sensitive information it 
stores, such as execution related information and/or encryption 
key related information. To provide further SPU operation, such 
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destroyed information would have to be replaced by a VDE 
clearinghouse, administrator and/or distributor, as may be 
appropriate. This may be achieved by remotely downloading 
update and/or replacement data and/or code. In the event of a 
disabling and/or destruction of processes and/or information as 
described above, the electronic appliance 600 may require a 
secure VDE communication with an administrator, 
clearinghouse, and/or distributor as appropriate in order to 
reinitialize the RTC 528. Some or all secure SPU 500 processes 
may not operate until then. 

It may be desirable to provide a mechanism for setting 
and/or synchronizing RTC 528. In the preferred embodiment, 
when communication occurs between VDE electronic appliance 
600 and another VDE appliance, an output of RTC 528 may be 
compared to a controlled RTC 528 output time under control of 
the party authorized to be "senior" and controlling. In the event 
of a discrepancy, appropriate action may be taken, including 
resetting the RTC 528 of the "junior" controlled participant in the 
communication. 

SPU Encrypt/Decrypt Engine 522 
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In the preferred embodiment, SPU encrypt/decrypt engine 
522 provides special purpose hardware (e.g., a hardware state 
machine) for rapidly and efficiently encrypting and/or decrypting 
data. In some implementations, the encrypt/decrypt functions 
may be performed instead by microprocessor 520 under software 
control, but providing special purpose encrypt/decrypt hardware 
engine 522 will, in general, provide increased performance. 
Microprocessor 520 may, if desired, comprise a combination of 
processor circuitry and dedicated encryption/decryption logic that 
may be integrated together in the same circuitry layout so as to, 
for example, optimally share one or more circuit elements. 

Generally, it is preferable that a computationally efficient 
but highly secure "bulk* encryption/decryption technique should 
be used to protect most of the data and objects handled by SPU 
500. It is preferable that an extremely secure 
encryption/decryption technique be used as an aspect of 
authenticating the identity of electronic appliances 600 that are 
establishing a communication channel and securing any 
transferred permission, method, and administrative information. 
In the preferred embodiment, the encrypt/decrypt engine 522 
includes both a symmetric key encryption/decryption circuit (e.g. 
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DES, Skipjack/Clipper, IDEA, RC-2, RC-4, etc.) and an 
antisymmetric (asymmetric) or Public Key ("PK") 
encryption/decryption circuit. The public/private key 
encryption/decryption circuit is used principally as an aspect of 
5 secure communications between an SPU 500 and VDE 

administrators, or other electronic appliances 600, that is 
between VDE secure subsystems. A symmetric 
encryption/decryption circuit may be used for "bulk* encrypting 
and decrypting most data stored in secondary storage 662 of 
10 electronic appliance 600 in which SPU 500 resides. The 

symmetric key encryption/decryption circuit may also be used for 
encrypting and decrypting content stored within VDE objects 
300. 

DES or public/private key methods may be used for all 
encryption functions. In alternate embodiments, encryption and 
decryption methods other than the DES and pubhc/private key 
methods could be used for the various encryption related 
functions. For instance, other types of symmetric 
encryption/decryption techniques in which the same key is used 
for encryption and decryption could be used in place of DES 
encryption and decryption. The preferred embodiment can 



15 



20 
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support a plurality of decryption/encryption techniques using 
multiple dedicated circuits within encrypt/decrypt engine 522 
and/or the processing arrangement within SPU 500. 

Pattern Matching Engine 524 

Optional pattern ma tching engine 524 may provide special 
purpose hardware for performing pattern matching functions. 
One of the functions SPU 500 may perform is to 
validate/authenticate VDE objects 300 and other items. 
VaKdation/authentication often involves comparing long data 
strings to deter min e whether they compare in a predetermined 
way. In addition, certain forms of usage (such as logical and/or 
physical (contiguous) relatedness of accessed elements) may 
require searching potentially long strings of data for certain bit 
patterns or other significant pattern related metrics. Although 
pattern matching can be performed by SPU microprocessor 520 
under software control, providing special purpose hardware 
pattern matching engine 524 may speed up the pattern matching 
process. 

Compression/Decompression Engine 546 
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An optional compression/decompression engine 546 may be 
provided within an SPU 500 to, for example, compress and/or 
decompress content stored in, or released from, VDE objects 300. 
Compression/decompression engine 546 may implement one or 
more compression algorit hms using hardware circuitry to 
improve the performance of compression/decompression 
operations that would otherwise be performed by software 
operating on microprocessor 520, or outside SPU 500. 
Decompression is important in the release of data such as video 
and audio that is usually compressed before distribution and 
whose decompression speed is important. In some cases, 
information that is useful for usage monitoring purposes (such as 
record separators or other delimiters) is Tbidden" under a 
compression layer that must be removed before this information 
can be detected and used inside SPU 500. 

Random Number Generator 542 

Optional random number generator 542 may provide 
specialized hardware circuitry for generating random values (e.g., 
from inherently unpredictable physical processes such as 
quantum noise). Such random values are particularly useful for 
constructing encryption keys or unique identifiers, and for 



-204- 



initializing the generation of pseudo-random sequences. Random 
number generator 542 may produce values of any convenient 
length, including as small as a single bit per use. A random 
number of arbitrary size may be constructed by concatenating 
values produced by random number generator 542. A 
cryptographically strong pseudo-random sequence may be 
generated from a random key and seed generated with random 
number generator 542 and repeated encryption either with the 
encrypt/decrypt engine 522 or cryptographic algorithms in SPU 
500. Such sequences may be used, for example, in private 
headers to frustrate efforts to determine an encryption key 
through crypto analysis. 

Arithmetic Accelerator 544 

An optional arithmetic accelerator 544 may be provided 
within an SPU 500 in the form of hardware circuitry that can 
rapidly perform mathematical calculations such as multiplication 
and exponentiation involving large numbers. These calculations 
can, for example, be requested by microprocessor 520 or 
encrypt/decrypt engine 522, to assist in the computations 
required for certain asymmetric encryption/decryption 
operations. Such arithmetic accelerators are well-known to those 
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skilled in the art. In some implementations, a separate 
arithmetic accelerator 544 may be omitted and any necessary 
calculations may be performed by microprocessor 520 under 
software control. 



DMA Controller 526 

DMA controller 526 controls information transfers over 
address/data bus 536 without requiring microprocessor 520 to 
process each individual data transfer. Typically, microprocessor 
520 may write to DMA controller 526 target and destination 
addresses and the number of bytes to transfer, and DMA 
controller 526 may then automatically transfer a block of data 
between components of SPU 500 (e.g., from ROM 532 to RAM 
534, between encrypt/decrypt engine 522 and RAM 534, between 
bus interface unit 530 and RAM 534, etc.). DMA controller 526 
may have multiple ch anne ls to handle multiple transfers 
simultaneously. In some implementations, a separate DMA 
controller 526 may be omitted, and any necessary data 
movements may be performed by microprocessor 520 under 
software control. 



Bus Interface Unit (BIU) 630 
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Bus interface unit (BIU) 530 communicates information 
between SPU 500 and the outside world across the security 
barrier 502. BIU 530 shown in Figure 9 plus appropriate driver 
software may comprise the "appliance link" 510 shown in Figure 
5 6. Bus interface unit 530 may be modelled after a USART or PCI 

bus interface in the preferred embodiment. In this example, BIU 
530 connects SPU 500 to electronic appliance system bus 653 
shown in Figure 8. BIU 530 is designed to prevent unauthorized 
access to internal components within SPU 500 and their 
10 contents. It does this by only allowing signals associated with an 

SPU 500 to be processed by control programs running on 
microprocessor 520 and not supporting direct access to the 
internal elements of an SPU 500. 



15 Memory Management Unit 540 

Memory Management Unit (MMU) 540, if present, 
provides hardware support for memory management and virtual 
memory management functions. It may also provide heightened 
security by enforcing hardware compartmentalization of the 

20 secure execution space (e.g., to prevent a less trusted task from 

modifying a more trusted task). More details are provided below 
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in connection with a discussion of the architecture of a Secure 
Processing Environment ("SPE") 503 supported by SPU 500. 

MMU 540 may also provide hardware-level support 
functions related to memory management such as, for example, 
address mapping. 

SPU Memory Architecture 

In the preferred embodiment, SPU 500 uses three general 
kinds of memory: 

(1) internal ROM 532; 

(2) internal RAM 534; and 

(3) external memory (typically RAM and/or disk supplied 
by a host electronic appliance). 

The internal ROM 532 and RAM 534 within SPU 500 
provide a secure operating environment and execution space. 
Because of cost limitations, chip fabrication size, complexity and 
other limitations, it may not be possible to provide sufficient 
memory within SPU 500 to store all information that an SPU 
needs to process in a secure manner. Due to the practical limits 
on the amount of ROM 532 and RAM 534 that may be included 
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within SPU 500, SPU 500 may store information in memory 
external to it, and move this information into and out of its 
secure internal memory space on an as needed basis. In these 
cases, secure processing steps performed by an SPU typically 
must be segmented into small, securely packaged elements that 
may be "paged in" and "paged out" of the limited available 
internal memory space. Memory external to an SPU 500 may not 
be secure. Since the external memory may not be secure, SPU 
500 may encrypt and cryptographically seal code and other 
information before storing it in external memory. Similarly, SPU 
500 must typically decrypt code and other information obtained 
from external memory in encrypted form before processing (e.g., 
executing) based on it. In the preferred embodiment, there are 
two general approaches used to address potential memory 
limitations in a SPU 500. In the first case, the small, securely 
packaged elements represent information contained in secure 
database 610. In the second case, such elements may represent 
protected (e.g., encrypted) virtual memory pages. Although 
virtual memory pages may correspond to information elements 
stored in secure database 610, this is not required in this 
example of a SPU memory architecture. 
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The following is a more detailed discussion of each of these 
three SPU memory resources. 

SPU Internal ROM 

SPU 500 read only memory (ROM) 532 or comparable 
purpose device provides secure internal non-volatile storage for 
certain programs and other information. For example, ROM 532 
may store "kernel" programs such as SPU control firmware 508 
and, if desired, encryption key information and certain 
fundamental "load modules." The "kernel" programs, load 
module information, and encryption key information enable the 
control of certain basic functions of the SPU 500. Those 
components that are at least in part dependent on device 
configuration (e.g., POST, memory allocation, and a dispatcher) 
may be loaded in ROM 532 along with additional load modules 
that have been determined to be required for specific 
installations or applications. 

In the preferred embodiment, ROM 532 may comprise a 
combination of a masked ROM 532a and an EEPROM and/or 
equivalent "flash" memory 532b. EEPROM or flash memory 
532b is used to store items that need to be updated and/or 
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initialized, such as for example, certain encryption keys. An 
additional benefit of providing EEPROM and/or flash memory 
532b is the ability to optimize any load modules and library 
functions persistently stored within SPU 500 based on typical 
usage at a specific site. Although these items could also be 
stored in NVRAM 534b, EEPROM and/or flash memory 532b 
may be more cost effective. 

Masked ROM 532a may cost less than flash and/or 
EEPROM 532b, and can be used to store permanent portions of 
SPU software/firmware. Such permanent portions may include, 
for example, code that interfaces to hardware elements such as 
the RTC 528, encryption/decryption engine 522, interrupt 
handlers, key generators, etc. Some of the operating system, 
library calls, libraries, and many of the core services provided by 
SPU 500 may also be in masked ROM 532a. In addition, some of 
the more commonly used executables are also good candidates for 
inclusion in masked ROM 532a. Items that need to be updated or 
that need to disappear when power is removed from SPU 500 
should not be stored in masked ROM 532a. 
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Under some circumstances, RAM 534a and/or NVRAM 
534b (NVRAM 534b may, for example, be constantly powered 
conventional RAM) may perform at least part of the role of ROM 
532. 

SPU Internal RAM 

SPU 500 general purpose RAM 534 provides, among other 
things, secure execution space for secure processes. In the 
preferred embodiment, RAM 534 is comprised of different types 
of RAM such as a combination of high-speed RAM 534a and an 
NVRAM ("non-volatile RAM") 534b. RAM 534a may be volatile, 
while NVRAM 534b is preferably battery backed or otherwise 
arranged so as to be non-volatile (i.e., it does not lose its contents 
when power is turned off). 

High-speed RAM 534a stores active code to be executed 
and associated data structures. 

NVRAM 534b preferably contains certain keys and 
summary values that are preloaded as part of an initialization 
process in which SPU 500 communicates with a VDE 
administrator, and may also store changeable or changing 
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information associated with the operation of SPU 500. For 
security reasons, certain highly sensitive information (e.g., 
certain load modules and certain encryption key related 
information such as internally generated private keys) needs to 
be loaded into or generated internally by SPU 500 from time to 
time but, once loaded or generated internally, should never leave 
the SPU. In this preferred embodiment, the SPU 500 
non-volatile random access memory (NVRAM) 534b may be used 
for securely storing such highly sensitive information. NVRAM 
534b is also used by SPU 500 to store data that may change 
frequently but which preferably should not be lost in a power 
down or power fail mode. 

NVRAM 534b is preferably a flash memory array, but may 
in addition or alternatively be electrically erasable programmable 
read only memory (EEPROM), static RAM (SRAM), bubble 
memory, three dimensional holographic or other electro-optical 
memory, or the like, or any other writable (e.g., randomly 
accessible) non-volatile memory of sufficient speed and 
cost-effectiveness. 

SPU External Memory 
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The SPU 500 can store certain information on memory 
devices external to the SPU. If available, electronic appliance 600 
memory can also be used to support any device external portions 
of SPU 500 software. Certain advantages may be gained by 
allowing the SPU 500 to use external memory. As one example, 
memory internal to SPU 500 may be reduced in size by using 
non-volatile read/write memory in the host electronic appliance 
600 such as a non-volatile portion of RAM 656 and/or ROM 658. 

Such external memory may be used to store SPU 
programs, data and/or other information. For example, a VDE 
control program may be, at least in part, loaded into the memory 
and communicated to and decrypted within SPU 500 prior to 
execution. Such control programs may be re-encrypted and 
communicated back to external memory where they may be 
stored for later execution by SPU 500. "Kernel" programs and/or 
some or all of the non-kernel "load modules" may be stored by 
SPU 500 in memory external to it. Since a secure database 610 
may be relatively large, SPU 500 can store some or all of secure 
database 610 in external memory and call portions into the SPU 
500 as needed. 
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As mentioned above, memory external to SPU 500 may not 
be secure. Therefore, when security is required, SPU 500 must 
encrypt secure information before writing it to external memory, 
and decrypt secure information read from external memory 
5 before using it. Inasmuch as the encryption layer relies on secure 

processes and information (e.g., encryption algorithms and keys) 
present within SPU 500, the encryption layer effectively 
"extends" the SPU security barrier 502 to protect information the 
SPU 500 stores in memory external to it. 

10 

SPU 500 can use a wide variety of different types of 
external memory. For example, external memory may comprise 
j electronic appliance secondary storage 652 such as a disk; 
external EEPROM or flash memory 658; and/or external RAM 
15 656. External RAM 656 may comprise an external nonvolatile 

(e.g. constantly powered) RAM and/or cache RAM. 

Using external RAM local to SPU 500 can significantly 
improve access times to information stored externally to an SPU. 
20 For example, external RAM may be used: 

C to buffer memory image pages and data structures prior to 

their storage in flash memory or on an external hard disk 
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(assuming transfer to flash or hard disk can occur in 

significant power or system failure cases); 
C provide encryption and decryption buffers for data being 

released from VDE objects 300. 
C to cache "swap blocks" and VDE data structures currently 

in use as an aspect of providing a secure virtual memory 

environment for SPU 500. 
C to cache other information in order to, for example, reduce 

frequency of access by an SPU to secondary storage 652 

and/or for other reasons. 
Dual ported external RAM can be particularly effective in 
improving SPU 500 performance, since it can decrease the data 
movement overhead of the SPU bus interface unit 530 and SPU 
microprocessor 520. 

Using external flash memory local to SPU 500 can be used 
to significantly improve access times to virtually all data 
structures. Since most available flash storage devices have 
limited write lifetimes, flash storage needs to take into account 
the number of writes that will occur during the lifetime of the 
flash memory. Hence, flash storage of frequently written 
temporary items is not recommended. If external RAM is non- 
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volatile, then transfer to flash (or hard disk) may not be 
necessary. 

External memory used by SPU 500 may include two 
categories: 

C external memory dedicated to SPU 500, and 
C memory shared with electronic appliance 600, 

For some VDE implementations, sharing memory (e.g., 
electronic appliance RAM 656, ROM 658 and/or secondary 
storage 652) with CPU 654 or other elements of an electronic 
appliance 600 may be the most cost effective way to store VDE 
secure database management files 610 and information that 
needs to be stored external to SPU 500. A host system hard disk 
secondary memory 652 used for general purpose file storage can, 
for example, also be used to store VDE management files 610. 
SPU 500 may be given exclusive access to the external memory 
(e.g., over a local bus high speed connection provided by BIU 
530). Both dedicated and shared external memory may be 
provided. 

****** 



-217- 



The hardware configuration of an example of electronic 
appliance 600 has been described above. The following section 
describes an example of the software architecture of electronic 
appliance 600 provided by the preferred embodiment, including 
the structure and operation of preferred embodiment "Rights 
Operating System" CROS«) 602. 

Rights Operating System 602 

Rights Operating System ("ROS") 602 in the preferred 
embodiment is a compact, secure, event-driven, services-based, 
"component" oriented, distributed multiprocessing operating 
system environment that integrates VDE information security 
control information, components and protocols with traditional 
operating system concepts. Like traditional operating systems, 
ROS 602 provided by the preferred embodiment is a piece of 
software that manages hardware resources of a computer system 
and extends management functions to input and/or output 
devices, including communications devices. Also like traditional 
operating systems, preferred embodiment ROS 602 provides a 
coherent set of basic functions and abstraction layers for hiding 
the differences between, and many of the detailed complexities of, 
particular hardware implementations. In addition to these 
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characteristics found in many or most operating systems, ROS 
602 provides secure VDE transaction management and other 
advantageous features not found in other operating systems. The 
following is a non-exhaustive list of some of the advantageous 
features provided by ROS 602 in the preferred embodiment: 

Standardized interface? provides coherent set of basic functions 
C simplifies programming 

C the same application can run on many different platforms 
Event driven 

C eases functional decomposition 
C extendible 

C accommodates state transition and/or process oriented 
events 

C simplifies task management 

C simplifies inter-process communications 

Services based 

C allows simplified and transparent scalability 

C simplifies multiprocessor support 

C hides machine dependencies 

C eases network management and support 

CorapofleRt Based Architecture 
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C processing based on independently deliverable secure 
components 

C component model of processing control allows different 
sequential steps that are reconfigurable based on 
requirements 

C components can be added, deleted or modified (subject to 
permissioning) 

C full control information over pre-defined and user-defined 

application events 
C events can be individually controlled with independent 

executables 
Secure 

C secure communications 
C secure control functions 
C secure virtual memory management 
C information control structures protected from exposure 
C data elements are validated, correlated and access 
controlled 

C components are encrypted and validated independently 
C components are tightly correlated to prevent unauthorized 
use of elements 
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C control structures and secured executables are validated 

prior to use to protect against tampering 
C integrates security considerations at the VO level 
C provides on-the-fly decryption of information at release 
5 time 

C enables a secure commercial transaction network 

C flexible key management features 

Scalagble 

C highly scalaeble across many different platforms 
10 C supports concurrent processing in a multiprocessor 

environment 
C supports multiple cooperating processors 
C any number of host or security processors can be supported 
C control structures and kernel are easily portable to various 
15 host platforms and to different processors within a target 

platform without recompilation 
C supports remote processing 

C Remote Procedure Calls may be used for internal OS 

communications 
20 Highly fotegratobfe 

C can be highly integrated with host platforms as an 

additional operating system layer 
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C permits non-secure storage of secured components and 
information using an OS layer "on top of traditional OS 
platforms 

C can be seamlessly integrated with a host operating system 
to provide a common usage paradigm for transaction 
management and content access 

C integration may take many forms: operating system layers 
for desktops (e.g., DOS, Windows, Macintosh); device 
drivers and operating system interfaces for network 
services (e.g, Unix and Netware); and dedicated component 
drivers for "low end" set tops are a few of many examples 

C can be integrated in traditional and real time operating 
systems 

Pjsfributgd 

C provides distribution of control information and reciprocal 

control information and mechanisms 
C supports conditional execution of controlled processes 

within any VDE node in a distributed, asynchronous 

arrangement 

C controlled delegation of rights in a distributed environment 
C supports chains of handling and control 
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C management environment for distributed, occasionally 

connected but otherwise asynchronous networked database 
C real time and time independent data management 
C supports "agent" processes 
Transparent 

C can be seamlessly integrated into existing operating 
systems 

C can support applications not specifically written to use it 
Network friendly 

C internal OS structures may use RPCs to distribute 
processing 

C subnets may seamlessly operate as a single node or 
independently 

General Background Regarding Operating Systems 

An "operating system" provides a control mechanism for 
organizing computer system resources that allows programmers 
to create applications for computer systems more easily. An 
operating system does this by providing commonly used 
functions, and by helping to ensure compatibility between 
different computer hardware and architectures (which may, for 
example, be manufactured by different vendors). Operating 
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systems also enable computer "peripheral device" manufacturers 
to far more easily supply compatible equipment to computer 
manufacturers and users. 

Computer systems are usually made up of several different 
hardware components. These hardware components include, for 
example: 

a central processing unit (CPU) for executing instructions; 

an array of main memory cells (e.g., "RAM" or "ROM") for 
storing instructions for execution and data acted upon or 
parameterizi n g those instructions; and 

one or more secondary storage devices (e.g., hard disk 
drive, floppy disk drive, CD-ROM drive, tape reader, card 
reader, or "flash" memory) organized to reflect named 
elements (a "file system") for storing images of main 
memory cells. 

Most computer systems also include input/output devices such as 
keyboards, mice, video systems, printers, scanners and 
communications devices. 
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To organize the CPtPs execution capabilities with available 
RAM, ROM and secondary storage devices, and to provide 
commonly used functions for use by programmers, a piece of 
software called an "operating system" is usually included with 
the other components. Typically, this piece of software is 
designed to begin executing after power is applied to the 
computer system and hardware diagnostics are completed. 
Thereafter, all use of the CPU, main memory and secondary 
memory devices is normally managed by this "operating system" 
software. Most computer operating systems also typically include 
a mechanism for extending their management functions to I/O 
and other peripheral devices, including commonly used functions 
associated with these devices. 

By managing the CPU, memory and peripheral devices 
through the operating system, a coherent set of basic functions 
and abstraction layers for hiding hardware details allows 
programmers to more easily create sophisticated applications. In 
addition, managing the computer's hardware resources with an 
operating system allows many differences in design and 
equipment requirements between different manufacturers to be 
hidden. Furthermore, applications can be more easily shared 
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with other computer users who have the same operating system, 
with significantly less work to support different manufacturers' 
base hardware and peripheral devices. 

5 ROS 602 is an Operating System Providing Significant 

Advantages 

ROS 602 is an "operating system" It manages the 
resources of electronic appliance 600, and provides a commonly 
used set of functions for programmers writing applications 608 

10 for the electronic appliance. ROS 602 in the preferred 

embodiment manages the hardware (e.g., CPU(s), memory(ies), 
secure RTC(s), and encrypt/decrypt engines) within SPU 500. 
ROS may also manage the hardware (e.g., CPU(s) and 
memory(ies)) within one or more general purpose processors 

15 within electronic appliance 600. ROS 602 also manages other 

electronic appliance hardware resources, such as peripheral 
devices attached to an electronic appliance. For example, 
referring to Figure 7, ROS 602 may manage keyboard 612, 
display 614, modem 618, disk drive 620, printer 622, scanner 624. 

20 ROS 602 may also manage secure database 610 and a storage 

device (e.g., "secondary storage" 652) used to store secure 
database 610. 
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ROS 602 supports multiple processors. ROS 602 in the 
preferred embodiment supports any number of local and/or 
remote processors. Supported processors may include at least 
two types: one or more electronic appliance processors 654, 
and/or one or more SPUs 500. A host processor CPU 654 may 
provide storage, database, and communications services. SPU 
500 may provide cryptographic and secured process execution 
services. Diverse control and execution structures supported by 
ROS 602 may require that processing of control information occur 
within a controllable execution space - this controllable 
execution space may be provided by SPU 500. Additional host 
and/or SPU processors may increase efficiencies and/or 
capabilities. ROS 602 may access, coordinate and/or manage 
further processors remote to an electronic appliance 600 (e.g., via 
network or other communications link) to provide additional 
processor resources and/or capabilities. 

ROS 602 is services based. The ROS services provided 
using a host processor 654 and/or a secure processor (SPU 500) 
are linked in the preferred embodiment using a "Remote 
Procedure Call" CRPC") internal processing request structure. 
Cooperating processors may request interprocess services using a 
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RPC mechanism, which is minimally time dependent and can be 
distributed over cooperating processors on a network of hosts. 
The multi-processor architecture provided by ROS 602 is easily 
extensible to support any number of host or security processors. 
This extensibility supports high levels of scalability. Services 
also allow functions to be implemented differently on different 
equipment. For example, a small appliance that typically has low 
levels of usage by one user may implement a database service 
using very different techniques than a very large appliance with 
high levels of usage by many users. This is another aspect of 
scalability. 

ROS 602 provides a distributed processing environment. 
For example, it permits information and control structures to 
automatically, securely pass between sites as required to fulfill a 
user's requests. Communications between VDE nodes under the 
distributed processing features of ROS 602 may include 
interprocess service requests as discussed above. ROS 602 
supports conditional and/or state dependent execution of 
controlled processors within any VDE node. The location that 
the process executes and the control structures used may be 
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locally resident, remotely accessible, or carried along by the 
process to support execution on a remote system. 

ROS 602 provides distribution of control information, 
including for example the distribution of control structures 
required to permit "agents" to operate in remote environments. 
Thus, ROS 602 provides facilities for passing execution and/or 
information control as part of emerging requirements for "agent" 
processes. 

If desired, ROS 602 may independently distribute control 
information over very low bandwidth connections that may or 
may not be "real time" connections. ROS 602 provided by the 
preferred embodiment is "network friendly," and can be 
implemented with any level of networking protocol. Some 
examples include e-mail and direct connection at approximately 
"Layer 5" of the ISO model. 

The ROS 602 distribution process (and the associated 
auditing of distributed information) is a controlled event that 
itself uses such control structures. This "reflective" distributed 
processing mechanism permits ROS 602 to securely distribute 
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rights and permissions in a controlled manner, and effectively 
restrict the characteristics of use of information content. The 
controlled delegation of rights in a distributed environment and 
the secure processing techniques used by ROS 602 to support this 
approach provide significant advantages. 

Certain control mechanisms within ROS 602 are 
"reciprocal." Reciprocal control mechanisms place one or more 
control components at one or more locations that interact with 
one or more components at the same or other locations in a 
controlled way. For example, a usage control associated with 
object content at a user's location may have a reciprocal control at 
a distributor's location that governs distribution of the usage 
control, auditing of the usage control, and logic to process user 
requests associated with the usage control. A usage control at a 
user's location (in addition to controlling one or more aspects of 
usage) may prepare audits for a distributor and format requests 
associated with the usage control for processing by a distributor. 
Processes at either end of a reciprocal control may be further 
controlled by other processes (e.g., a distributor may be limited by 
a budget for the number of usage control mechanisms they may 
produce). Reciprocal control mechanisms may extend over many 
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sites and many levels (e.g., a creator to a distributor to a user) 
and may take any relationship into account (e.g., 
creator/distributor, distributor/user, user/user, user/creator, 
user/creator/distributor, etc.) Reciprocal control mechanisms 
have many uses in VDE 100 in representing relationships and 
agreements in a distributed environment. 

ROS 602 is scalable. Many portions of ROS 602 control 
structures and kerneKs) are easily portable to various host 
platforms without recompilation. Any control structure may be 
distributed (or redistributed) if a granting authority permits this 
type of activity. The executable references within ROS 602 are 
portable within a target platform. Different instances of ROS 602 
may execute the references using different resources. For 
example, one instance of ROS 602 may perform a task using an 
SPU 500, while another instance of ROS 602 might perform the 
same task using a host processing environment running in 
protected memory that is emulating an SPU in software. ROS 
602 control informationis similarly portable; in many cases the 
event processing structures may be passed between machines 
and host platforms as easily as between cooperative processors in 
a single computer. Appliances with different levels of usage 
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and/or resources available for ROS 602 functions may implement 
those functions in very different ways. Some services may be 
omitted entirely if insufficient resources exist. As described 
elsewhere, ROS 602 "knows" what services are available, and 
how to proceed based on any given event. Not all events may be 
processable if resources are missing or inadequate. 

ROS 602 is component based. Much of the functionality 
provided by ROS 602 in the preferred embodiment may be based 
on "components" that can be securely, independently deliverable, 
replaceable and capable of being modified (e.g., under 
appropriately secure conditions and authorizations). Moreover, 
the "components" may themselves be made of independently 
deliverable elements. ROS 602 may assemble these elements 
together (using a construct provided by the preferred 
embodiment called a "channel") at execution time. For example, 
a "load module" for execution by SPU 500 may reference one or 
more "method cores," method parameters and other associated 
data structures that ROS 602 may collect and assemble together 
to perform a task such as billing or metering. Different users 
may have different combinations of elements, and some of the 
elements may be customizable by users with appropriate 
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authorization. This increases flexibility, allows elements to be 
reused, and has other advantages, 

ROS 602 is highly secure. ROS 602 provides mechanisms 
to protect information control structures from exposure by end 
users and conduit hosts. ROS 602 can protect information, VDE 
control structures and control executables using strong 
encryption and validation mechanisms. These encryption and 
validation mechanisms are designed to make them highly 
resistant to undetected tampering. ROS 602 encrypts 
information stored on secondary storage device(s) 652 to inhibit 
tampering. ROS 602 also separately encrypts and validates its 
various components. ROS 602 correlates control and data 
structure components to prevent unauthorized use of elements. 
These features permit ROS 602 to independently distribute 
elements, and also allows integration of VDE functions 604 with 
non-secure "other" OS functions 606. 

ROS 602 provided by the preferred embodiment extends 
conventional capabilities such as, for example, Access Control 
List (ACL) structures, to user and process defined events, 
including state transitions. ROS 602 may provide full control 
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information over pre-defined and user-defined application events. 
These control mechanisms include "go/no-go" permissions, and 
also include optional event-specific executables that permit 
complete flexibility in the processing and/or controlling of events. 
This structure permits events to be individually controlled so 
that, for example, metering and budgeting may be provided using 
independent executables. For example, ROS 602 extends ACL 
structures to control arbitrary granularity of information. 
Traditional operating systems provide static "go-no go" control 
mechanisms at a file or resource level; ROS 602 extends the 
control concept in a general way from the largest to the smallest 
sub-element using a flexible control structure. ROS 602 can, for 
example, control the printing of a single paragraph out of a 
document file. 

ROS 602 provided by the preferred embodiment permits 
secure modification and update of control information governing 
each component. The control information may be provided in a 
template format such as method options to an end-user. An 
end-user may then customize the actual control information used 
within guidelines provided by a distributor or content creator. 
Modification and update of existing control structures is 
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preferably also a controllable event subject to auditing and 
control information. 

ROS 602 provided by the preferred embodiment validates 
5 control structures and secured executables prior to use. This 

validation provides assurance that control structures and 
executables have not been tampered with by end-users. The 
validation also permits ROS 602 to securely implement 
components that include fragments of files and other operating 

10 system structures. ROS 602 provided by the preferred 

embodiment integrates security considerations at the operating 
system I/O level (which is below the access level), and provides 
"on-the-fly" decryption of information at release time. These 
features permit non-secure storage of ROS 602 secured 

15 components and information using an OS layer "on top of" 

traditional operating system platforms. 

ROS 602 is highly integratable with host platforms as an 
additional operating system layer. Thus, ROS 602 may be 
20 created by "adding on a to existing operating systems. This 

involves hooking VDE "add ons" to the host operating system at 
the device driver and network interface levels. Alternatively, 
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ROS 602 may comprise a wholly new operating system that 
integrates both VDE functions and other operating system 
functions. 

5 Indeed, there are at least three general approaches to 

integrating VDE functions into a new operating system, 
potentially based on an existing operating system, to create a 
Rights Operating System 602 including: 

(1) Redesign the operating system based on VDE 
10 transaction management requirements; 

(2) Compile VDE API functions into an existing operating 
systems; and 

(3) Integrate a VDE Interpreter into an existing operating 
system. 

15 

The first approach could be most effectively applied when a 
new operating system is being designed, or if a significant 
upgrade to an existing operating system is planned. The 
transaction management and security requirements provided by 
20 the VDE functions could be added to the design requirements list 

for the design of a new operating system that provides, in an 
optimally efficient manner, an integration of "traditional" 
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operating system capabilities and VDE capabilities. For example, 
the engineers responsible for the design of the new version or 
instance of an operating system would include the requirements 
of VDE metering/transaction management in addition to other 
requirements (if any) that they use to form their design approach, 
specifications, and actual implementations. This approach could 
lead to a "seamless" integration of VDE functions and capabilities 
by threading metering/transaction management functionality 
throughout the system design and implementation. 

The second approach would involve taking an existing set 
of API (Application Programmer Interface) functions, and 
incorporating references in the operating system code to VDE 
function calls. This is similar to the way that the current 
Windows operating system is integrated with DOS, wherein DOS 
serves as both the launch point and as a significant portion of the 
kernel underpinning of the Windows operating system. This 
approach would be also provide a high degree of "seamless" 
integration (although not quite as "seamless" as the first 
approach). The benefits of this approach include the possibility 
that the incorporation of metering/transaction management 
ftmctionality into the new version or instance of an operating 
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system may be accomplished with lower cost (by making use of 
the existing code embodied in an API, and also using the design 
implications of the API functional approach to influence the 
design of the elements into which the metering/transaction 
management functionality is incorporated). 

The third approach is distinct from the first two in that it 
does not incorporate VDE functionality associated with 
metering/transaction management and data security directly into 
the operating system code, but instead adds a new generalized 
capability to the operating system for executing 
metering/transaction management functionality. In this case, an 
interpreter including metering/transaction management 
functions would be integrated with other operating system code 
in a "stand alone" mode. This interpreter might take scripts or 
other inputs to determine what metering/transaction 
management functions should be performed, and in what order 
and under which circumstances or conditions they should be 
performed. 

Instead of (or in addition to) integrating VDE functions 
into/with an electronic appliance operating system, it would be 
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possible to provide certain VDE functionality available as an 
application running on a conventional operating system. 

ROS Software Architecture 
5 Figure 10 is a block diagram of one example of a software 

structure/architecture for Rights Operating System ("ROS") 602 
provided by the preferred embodiment. In this example, ROS 
602 includes an operating system ("OS") "core" 679, a user 
Application Program Interface ("API") 682, a "redirector" 684, an 

10 "intercept" 692, a User Notification/Exception Interface 686, and 

a file system 687. ROS 602 in this example also includes one or 
more Host Event Processing Environments ("HPEs") 655 and/or 
one or more Secure Event Processing Environments ("SPEs") 503 
(these environments may be generically referred to as "Protected 

15 Processing Environments" 650). 

HPE(s) 655 and SPE(s) 503 are self-contained computing 
and processing environments that may include their own 
operating system kernel 688 including code and data processing 
20 resources. A given electronic appliance 600 may include any 

number of SPE(s) 503 and/or any number of HPE(s) 655. HPE(s) 
655 and SPE(s) 503 may process information in a secure way, 
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and provide secure processing support for ROS 602, For 
example, they may each perform secure processing based on one 
or more VDE component assemblies 690, and they may each offer 
secure processing services to OS kernel 680. 

In the preferred embodiment, SPE 503 is a secure 
processing environment provided at least in part by an SPU 500. 
Thus, SPU 500 provides the hardware tamper-resistant barrier 
503 surrounding SPE 503. SPE 503 provided by the preferred 
embodiment is preferably: 

C small and compact 

C loadable into resource constrained 

environments such as for example minimally 
configured SPUs 500 
C dynamically updatable 
C extensible by authorized users 
C integratable into object or procedural 

environments 
C secure. 

In the preferred embodiment, HPE 655 is a secure 
processing environment supported by a processor other than an 
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SPU, such as for example an electronic appliance CPU 654 
general-purpose microprocessor or other processing system or 
device. In the preferred embodiment, HPE 655 may be 
considered to "emulate" an SPU 500 in the sense that it may use 
software to provide some or all of the processing resources 
provided in hardware and/or firmware by an SPU. HPE 655 in 
one preferred embodiment of the present invention is full- 
featured and fully compatible with SPE 503— that is, HPE 655 
can handle each and every service call SPE 503 can handle such 
that the SPE and the HPE are "plug compatible" from an outside 
interface standpoint (with the exception that the HPE may not 
provide as much security as the SPE). 

HPEs 655 may be provided in two types: secure and not 
secure. For example, it may be desirable to provide non-secure 
versions of HPE 655 to allow electronic appliance 600 to 
efficiently run non-sensitive VDE tasks using the full resources of 
a fast general purpose processor or computer. Such non-secure 
versions of HPE 655 may run under supervision of an instance of 
ROS 602 that also includes an SPE 503. In this way, ROS 602 
may run all secure processes within SPE 503, and only use HPE 
655 for processes that do not require security but that may 
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require (or run more efficiently) under potentially greater 
resources provided by a general purpose computer or processor 
supporting HPE 655. Non-secure and secure HPE 655 may 
operate together with a secure SPE 503. 

HPEs 655 may (as shown in Figure 10) be provided with a 
software-based tamper resistant barrier 674 that makes them 
more secure. Such a software-based tamper resistant barrier 674 
may be created by software executing on general-purpose CPU 
654. Such a "secure" HPE 655 can be used by ROS 602 to 
execute processes that, while still needing security, may not 
require the degree of security provided by SPU 500. This can be 
especially beneficial in architectures providing both an SPE 503 
and an HPE 655. The SPU 502 may be used to perform all truly 
secure processing, whereas one or more HPEs 655 may be used to 
provide additional secure (albeit possibly less secure than the 
SPE) processing using host processor or other general purpose 
resources that may be available within an electronic appliance 
600. Any service may be provided by such a secure HPE 655. In 
the preferred embodiment, certain aspects of "channel 
processing" appears to be a candidate that could be readily 
exported from SPE 503 to HPE 655. 
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The software-based tamper resistant barrier 674 provided 
by HPE 655 may be provided, for example, by: introducing time 
checks and/or code modifications to complicate the process of 
stepping through code comprising a portion of kernel 688a and/or 
a portion of component assemblies 690 using a debugger; using a 
map of defects on a storage device (e.g., a hard disk, memory 
card, etc.) to form internal test values to impede moving and/or 
copying HPE 655 to other electronic appliances 600; using kernel 
code that contains false branches and other complications in flow 
of control to disguise internal processes to some degree from 
disassembly or other efforts to discover details of processes; using 
"self-generating" code (based on the output of a co-sine transform, 
for example) such that detailed and/or complete instruction 
sequences are not stored explicitly on storage devices and/or in 
active memory but rather are generated as needed; using code 
that "shuffles" memory locations used for data values based on 
operational parameters to complicate efforts to manipulate such 
values; using any software and/or hardware memory 
management resources of electronic appliance 600 to "protect" 
the operation of HPE 655 from other processes, functions, etc. 
Although such a software-based tamper resistant barrier 674 
may provide a fair degree of security, it typically will not be as 
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secure as the hardware-based tamper resistant barrier 502 
provided (at least in part) by SPU 500. Because security may be 
better/more effectively enforced with the assistance of hardware 
security features such as those provided by SPU 500 (and 
because of other factors such as increased performance provided 
by special purpose circuitry within SPU 500), at least one SPE 
503 is preferred for many or most higher security applications. 
However, in applications where lesser security can be tolerated 
and/or the cost of an SPU 500 cannot be tolerated, the SPE 503 
may be omitted and all secure processing may instead be 
performed by one or more secure HPEs 655 executing on 
general-purpose CPUs 654. Some VDE processes may not be 
allowed to proceed on reduced-security electronic appliances of 
this type if insufficient security is provided for the particular 
process involved. 

Only those processes that execute completely within SPEs 
503 (and in some cases, HPEs 655) may be considered to be truly 
secure. Memory and other resources external to SPE 503 and 
HPEs 655 used to store and/or process code and/or data to be 
used in secure processes should only receive and handle that 
information in encrypted form unless SPE 503/HPE 655 can 
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protect secure process code and/or data from non-secure 
processes. 

OS "core" 679 in the preferred embodiment includes a 
5 kernel 680, an RPC manager 732, and an "object switch" 734. 

API 682, HPE 655 and SPE 503 may communicate "event" 
messages with one another via OS "core" 679. They may also 
communicate messages directly with one another without 
messages going through OS "core" 679. 

10 

Kernel 680 may manage the hardware of an electronic 
appliance 600. For example, it may provide appropriate drivers 
and hardware managers for interacting with input/output and/or 
peripheral devices such as keyboard 612, display 614, other 

15 devices such as a "mouse" pointing device and speech recognizer 

613, modem 618, printer 622, and an adapter for network 672. 
Kernel 680 may also be responsible for initially loading the 
remainder of ROS 602, and may manage the various ROS tasks 
(and associated underlying hardware resources) during 

20 execution. OS kernel 680 may also manage and access secure 

database 610 and file system 687. OS kernel 680 also provides 
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execution services for applications 608a(l), 608a(2), etc. and other 
applications. 

RPC manager 732 performs messaging routing and 
resource management/integration for ROS 680. It receives and 
routes "calls" from/to API 682, HPE 655 and SPE 503, for 
example. 

Object switch 734 may manage construction, 
deconstruction and other manipulation of VDE objects 300. 

User Notification/Exception Interface 686 in the preferred 
embodiment (which may be considered part of API 682 or another 
application coupled to the API) provides "pop up" 
windows/displays on display 614. This allows ROS 602 to 
co mmunic ate directly with a user without having to pass 
information to be communicated through applications 608. For 
applications that are not "VDE aware," user 
notification/exception interface 686 may provide communications 
between ROS 602 and the user. 
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API 682 in the preferred embodiment provides a 
standardized, documented software interface to applications 608. 
In part, API 682 may translate operating system "calls* 
generated by applications 608 into Remote Procedure Calls 
("RPCs") specifying "events." RPC manager 732 may route these 
RPCs to kernel 680 or elsewhere (e.g., to HPE(s) 655 and/or 
SPE(s) 503, or to remote electronic appliances 600, processors, or 
VDE participants) for processing. The API 682 may also service 
RPC requests by passing them to applications 608 that register 
to receive and process specific requests. 

API 682 provides an "Applications Programming Interface" 
that is preferably standardized and documented. It provides a 
concise set of function calls an application program can use to 
access services provided by ROS 602. In at least one preferred 
example, API 682 will include two parts: an application program 
interface to VDE functions 604; and an application program 
interface to other OS functions 606. These parts may be 
interwoven into the same software, or they may be provided as 
two or more discrete pieces of software (for example). 
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Some applications, such as application 608a(l) shown in 
Figure 11, may be "VDE aware" and may therefore directly 
access both of these parts of API 682. Figure 11A shows an 
example of this. A "VDE aware" application may, for example, 
include explicit calls to ROS 602 requesting the creation of new 
VDE objects 300, metering usage of VDE objects, storing 
information in VDE-protected form, etc. Thus, a "VDE aware" 
application can initiate (and, in some examples, enhance and/or 
extend) VDE functionality provided by ROS 602. In addition, 
fr VDE aware" applications may provide a more direct interface 
between a user and ROS 602 (e.g., by suppressing or otherwise 
dispensing with "pop up" displays otherwise provided by user 
notification/exception interface 686 and instead providing a more 
"seamless" interface that integrates application and ROS 
messages). 

Other applications, such as application 608b shown in 
Figure 11B, may not be "VDE Aware" and therefore may not 
"know" how to directly access an interface to VDE functions 604 
provided by API 682. To provide for this, ROS 602 may include a 
"re director" 684 that allows such "non-VDE aware" applications 
608(b) to access VDE objects 300 and functions 604. Redirector 
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684, in the preferred embodiment, translates OS calls directed to 
the "other OS functions" 606 into calls to the "VDE functions" 
604. As one simple example, redirector 684 may intercept a "file 
open" call from application 608(b), determine whether the file to 
be opened is contained within a VDE container 300, and if it is, 
generate appropriate VDE function call(s) to file system 687 to 
open the VDE container (and potentially generate events to HPE 
655 and/or SPE 503 to determine the name(s) of file(s) that may 
be stored in a VDE object 300, establish a control structure 
associated with a VDE object 300, perform a registration for a 
VDE object 300, etc.). Without redirector 684 in this example, a 
non-VDE aware application such as 608b could access only the 
part of API 682 that provides an interface to other OS functions 
606, and therefore could not access any VDE functions. 

This "translation" feature of redirector 684 provides 
"transparency." It allows VDE functions to be provided to the 
application 608(b) in a "transparent" way without requiring the 
application to become involved in the complexity and details 
associated with generating the one or more calls to VDE 
functions 604. This aspect of the "transparency" features of ROS 
602 has at least two important advantages: 
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(a) it allows applications not written specifically for VDE 
functions 604 ("non-VDE aware applications") to 
nevertheless access critical VDE functions; and 

(b) it reduces the complexity of the interface between an 
application and ROS 602. 

Since the second advantage (reducing complexity) makes it easier 
for an application creator to produce applications, even "VDE 
aware" applications 608a(2) may be designed so that some calls 
invoking VDE functions 604 are requested at the level of an 
"other OS functions" call and then "translated" by redirector 684 
into a VDE function call (in this sense, redirector 684 may be 
considered a part of API 682). Figure 11C shows an example of 
this. Other calls invoking VDE functions 604 may be passed 
directly without translation by redirector 684. 

Referring again to Figure 10, ROS 620 may also include an 
"interceptor" 692 that transmits and/or receives one or more real 
time data feeds 694 (this may be provided over cable(s) 628 for 
example), and routes one or more such data feeds appropriately 
while providing "translation" functions for real time data sent 
and/or received by electronic appliance 600 to allow 
"transparency" for this type of information analogous to the 
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transparency provided by redirector 684 (and/or it may generate 
one or more real time data feeds). 

Secure ROS Components and Component Assemblies 

As discussed above, ROS 602 in the preferred embodiment 
is a component-based architecture. ROS VDE functions 604 may 
be based on segmented, independently loadable executable 
"component assemblies" 690. These component assemblies 690 
are independently securely deliverable. The component 
assemblies 690 provided by the preferred embodiment comprise 
code and data elements that are themselves independently 
deliverable. Thus, each component assembly 690 provided by the 
preferred embodiment is comprised of independently securely 
deliverable elements which may be communicated using VDE 
secure communication techniques, between VDE secure 
subsystems. 

These component assemblies 690 are the basic functional 
unit provided by ROS 602. The component assemblies 690 are 
executed to perform operating system or application tasks. Thus, 
some component assemblies 690 may be considered to be part of 
the ROS operating system 602, while other component 
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assemblies may be considered to be "applications" that run under 
the support of the operating system. As with any system 
incorporating "applications" and "operating systems," the 
boundary between these aspects of an overall system can be 
ambiguous. For example, commonly used "application" functions 
(such as dete rmining the structure and/or other attributes of a 
content container) may be incorporated into an operating system. 
Furthermore, "operating system" functions (such as task 
management, or memory allocation) may be modified and/or 
replaced by an application. A common thread in the preferred 
embodiment's ROS 602 is that component assemblies 690 provide 
functions needed for a user to fulfill her intended activities, some 
of which may be "application-like" and some of which may be 
"operating system-like." 

Components 690 are preferably designed to be easily 
separable and individually loadable. ROS 602 assembles these 
elements together into an executable component assembly 690 
prior to loading and executing the component assembly (e.g., in a 
secure operating environment such as SPE 503 and/or HPE 655). 
ROS 602 provides an element identification and referencing 
mechanism that includes information necessary to automatically 
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assemble elements into a component assembly 690 in a secure 
manner prior to, and/or during, execution. 

ROS 602 application structures and control parameters 
used to form component assemblies 690 can be provided by 
different parties. Because the components forming component 
assemblies 690 are independently securely deliverable, they may 
be delivered at different times and/or by different parties 
("delivery* may take place within a local VDE secure subsystem, 
that is submission through the use of such a secure subsystem of 
control information by a chain of content control information 
handling participant for the preparation of a modified control 
information set constitutes independent, secure delivery). For 
example, a content creator can produce a ROS 602 application 
that defines the circumstances required for licensing content 
contained within a VDE object 300. This application may 
reference structures provided by other parties. Such references 
might, for example, take the form of a control path that uses 
content creator structures to meter user activities; and structures 
created/owned by a financial provider to handle financial parts of 
a content distribution transaction (e.g., defining a credit budget 
that must be present in a control structure to establish 
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creditworthiness, audit processes which must be performed by 
the licensee, etc.). As another example, a distributor may give 
one user more favorable pricing than another user by delivering 
different data elements defining pricing to different users. This 
5 attribute of supporting multiple party securely, independently 

deliverable control information is fundamental to enabling 
electronic commerce, that is, defining of a content and/or 
appliance control information set that represents the 
requirements of a collection of independent parties such as 
10 content creators, other content providers, financial service 

providers, and/or users. 

In the preferred embodiment, ROS 602 assembles securely 
independently deliverable elements into a component assembly 

15 690 based in part on context parameters (e.g., object, user). 

Thus, for example, ROS 602 may securely assemble different 
elements together to form different component assemblies 690 for 
different users performing the same task on the same VDE object 
300. Similarly, ROS 602 may assemble differing element sets 

20 which may include, that is reuse, one or more of the same 

components to form different component assemblies 690 for the 
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same user performing the same task on different VDE objects 
300. 

The component assembly organization provided by ROS 
602 is "recursive" in that a component assembly 690 may 
comprise one or more component "subassemblies" that are 
themselves independently loadable and executable component 
assemblies 690. These component "subassemblies" may, in turn, 
be made of one or more component "sub-sub-assemblies." In the 
general case, a component assembly 690 may include N levels of 
component subassemblies. 

Thus, for example, a component assembly 690(k) that may 
includes a component subassembly 690(k + 1). Component 
subassembly 690(k + 1), in turn, may include a component sub- 
sub-assembly 690(3), ... and so on to N-level subassembly 690(k + 
N). The ability of ROS 602 to build component assemblies 690 
out of other component assemblies provides great advantages in 
terms of, for example, code/data reusability, and the ability to 
allow different parties to manage different parts of an overall 
component. 
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Each component assembly 690 in the preferred 
embodiment is made of distinct components. Figures 11D-11H 
are abstract depictions of various distinct components that may 
be assembled to form a component assembly 690(k) showing 
Figure 111. These same components can be combined in different 
ways (e.g., with more or less components) to form different 
component assemblies 690 providing completely different 
functional behavior. Figure 11J is an abstract depiction of the 
same components being put together in a different way (e.g., with 
additional components) to form a different component assembly 
690(j). The component assemblies 690(k) and 690(j) each include 
a common feature 691 that interlocks with a "channel" 594 
defined by ROS 602; This "channel" 594 assembles component 
assemblies 690 and interfaces them with the (rest of) ROS 602. 

ROS 602 generates component assemblies 690 in a secure 
maimer. As shown graphically in Figures 111 and 11J, the 
different elements comprising a component assembly 690 may be 
"interlocking" in the sense that they can only go together in ways 
that are intended by the VDE participants who created the 
elements and/or specified the component assemblies. ROS 602 
includes security protections that can prevent an unauthorized 
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person from modifying elements, and also prevent an 
unauthorized person from substituting elements. One can 
picture an unauthorized person making a new element having 
the same "shape" as the one of the elements shown in Figures 
11D-11H, and then attempting to substitute the new element in 
place of the original element. Suppose one of the elements shown 
in Figure 11H establishes the price for using content within a 
VDE object 300. If an unauthorized person could substitute her 
own "price" element for the price element intended by the VDE 
content distributor, then the person could establish a price of zero 
instead of the price the content distributor intended to charge. 
Similarly, if the element establishes an electronic credit card, 
then an ability to substitute a different element could have 
disastrous consequences in terms of allowing a person to charge 
her usage to someone else's (or a non-existent) credit card. These 
are merely a few simple examples demonstrating the importance 
of ROS 602 ensuring that certain component assemblies 690 are 
formed in a secure manner. ROS 602 provides a wide range of 
protections against a wide range of "threats" to the secure 
handling and execution of component assemblies 690. 
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In the preferred embodiment, ROS 602 assembles 
component assemblies 690 based on the following types of 
elements: 

Permissions Records (TERCs) 808; 

Method "Cores" 1000; 

Load Modules 1100; 

Data Elements (e.g., User Data Elements CUDEs") 1200 
and Method Data Elements ("MDEs") 1202); and 
Other component assemblies 690. 

Briefly, a PERC 808 provided by the preferred embodiment 
is a record corresponding to a VDE object 300 that identifies to 
ROS 602, among other things, the elements ROS is to assemble 
together to form a component assembly 690. Thus PERC 808 in 
effect contains a "list of assembly instructions" or a "plan" 
specifying what elements ROS 602 is to assemble together into a 
component assembly and how the elements are to be connected 
together. PERC 808 may itself contain data or other elements 
that are to become part of the component assembly 690. 
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The PERC 808 may reference one or more method "cores" 
1000N. A method core 1000N may define a basic "method" 1000 
(e.g., "control," "billing," "metering," etc.) 

In the preferred embodiment, a "method" 1000 is a 
collection of basic instructions, and information related to basic 
instructions, that provides context, data, requirements, and/or 
relationships for use in performing, and/or preparing to perform, 
basic instructions in relation to the operation of one or more 
electronic appliances 600. Basic instructions may be comprised 
of, for example: 

C machine code of the type commonly used in the 

programming of computers; pseudo-code for use by 
an interpreter or other instruction processing 
program operating on a computer; 

C a sequence of electronically represented logical 

operations for use with an electronic appliance 600; 

C or other electronic representations of instructions, 
source code, object code, and/or pseudo code as those 
terms are commonly understood in the arts. 
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Information relating to said basic instructions may 
comprise, for example, data associated intrinsically with basic 
instructions such as for example, an identifier for the combined 
basic instructions and intrinsic data, addresses, constants, and/or 
the like. The information may also, for example, include one or 
more of the following: 

C information that identifies associated basic 

instructions and said intrinsic data for access, 
correlation and/or validation purposes; 

C required and/or optional parameters for use with 
basic instructions and said intrinsic data; 

C information defining relationships to other methods; 

C data elements that may comprise data values, fields 
of information, and/or the like; 

C information specifying and/or defining relationships 
among data elements, basic instructions and/or 
intrinsic data; 

C information specifying relationships to external data 
elements; 
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C information specifying relationships between and 
among internal and external data elements, 
methods, and/or the like, if any exist; and 

C additional information required in the operation of 
basic instructions and intrinsic data to complete, or 
attempt to complete, a purpose intended by a user of 
a method, where required, including additional 
instructions and/or intrinsic data. 

Such information associated with a method may be stored, 
in part or whole, separately from basic instructions and intrinsic 
data. When these components are stored separately, a method 
may nevertheless include and encompass the other information 
and one or more sets of basic instructions and intrinsic data (the 
latter being included because of said other information's 
reference to one or more sets of basic instructions and intrinsic 
data), whether or not said one or more sets of basic instructions 
and intrinsic data are accessible at any given point in time. 

Method core 1000' may be parameterized by an "event 
code" to permit it to respond to different events in different ways. 
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For example, a METER method may respond to a "use" event by 
storing usage information in a meter data structure. The same 
METER method may respond to an "administrative" event by 
reporting the meter data structure to a VDE clearinghouse or 
other VDE participant. 

In the preferred embodiment, method core 1000* may 
"contain," either explicitly or by reference, one or more "load 
modules" 1100 and one or more data elements (UDEs 1200, 
MDEs 1202). In the preferred embodiment, a "load module" 1100 
is a portion of a method that reflects basic instructions and 
intrinsic data. Load modules 1100 in the preferred embodiment 
contain executable code, and may also contain data elements 
("DTDs" 1108) associated with the executable code. In the 
preferred embodiment, load modules 1100 supply the program 
instructions that are actually "executed" by hardware to perform 
the process defined by the method. Load modules 1100 may 
contain or reference other load modules. 

Load modules 1100 in the preferred embodiment are 
modular and "code pure" so that individual load modules may be 
reenterable and reusable. In order for components 690 to be 
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dynamically updatable, they may be individually addressable 
within a global public name space. In view of these design goals, 
load modules 1100 are preferably small, code (and code-like) pure 
modules that are individually named and addressable. A single 
method may provide different load modules 1100 that perform 
the same or similar functions on different platforms, thereby 
making the method scalable and/or portable across a wide range 
of different electronic appliances. 

UDEs 1200 and MDEs 1202 may store data for input to or 
output from executable component assembly 690 (or data 
describing such inputs and/or outputs). In the preferred 
embodiment, UDEs 1200 may be user dependent, whereas MDEs 
1202 may be user independent. 

The component assembly example 690(k) shown in Figure 
HE comprises a method core 1000', UDEs 1200a & 1200b, an 
MDE 1202, load modules HOOa-HOOd, and a further component 
assembly 690(k+l). As mentioned above, a PERC 808(k) defines, 
among other things, the "assembly instructions" for component 
assembly 690(k), and may contain or reference parts of some or 
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all of the components that are to be assembled to create a 
component assembly. 

One of the load modules 1100b shown in this example is 
itself comprised of plural load modules 1100c, llOOd. Some of the 
load modules (e.g., 1100a, llOOd) in this example include one or 
more "DTD* data elements 1108 (e.g., 1108a, 1108b). "DTD" data 
elements 1108 may be used, for example, to inform load module 
1100a of the data elements included in MDE 1202 and/or UDEs 
1200a, 1200b. Furthermore, DTDs 1108 may be used as an 
aspect of forming a portion of an application used to inform a 
user as to the information required and/or manipulated by one or 
more load modules 1100, or other component elements. Such an 
application program may also include functions for creating 
and/or manipulating UDE(s) 1200, MDE(s) 1202, or other 
component elements, subassemblies, etc. 

Components within component assemblies 690 may be 
"reused" to form different component assemblies. As mentioned 
above, figure 11F is an abstract depiction of one example of the 
same components used for assembling component assembly 
690(k) to be reused (e.g., with some additional components 
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specified by a different set of "assembly instructions" provided in 
a different PERC 808(1)) to form a different component assembly 
690(1). Even though component assembly 690(1) is formed from 
some of the same components used to form component assembly 
690(k), these two component assemblies may perform completely 
different processes in complete different ways. 

As mentioned above, ROS 602 provides several layers of 
security to ensure the security of component assemblies 690. One 
important security layer involves ensuring that certain 
component assemblies 690 are formed, loaded and executed only 
in secure execution space such as provided within an SPU 500. 
Components 690 and/or elements comprising them may be stored 
on external media encrypted using local SPU 500 generated 
and/or distributor provided keys. 

ROS 602 also provides a tagging and sequencing scheme 
that may be used within the loadable component assemblies 690 
to detect tampering by substitution. Each element comprising a 
component assembly 690 may be loaded into an SPU 500, 
decrypted using encrypt/decrypt engine 522, and then 
tested/compared to ensure that the proper element has been 
loaded. Several independent comparisons may be used to ensure 



-265- 



there has been no unauthorized substitution. For example, the 
public and private copies of the element ED may be compared to 
ensure that they are the same, thereby preventing gross 
substitution of elements. In addition, a validation/correlation tag 
stored under the encrypted layer of the loadable element may be 
compared to make sure it matches one or more tags provided by a 
requesting process. This prevents unauthorized use of 
information. As a third protection, a device assigned tag (e.g., a 
sequence number) stored under an encryption layer of a loadable 
element may be checked to make sure it matches a corresponding 
tag value expected by SPU 500. This prevents substitution of 
older elements. Validation/correlation tags are typically passed 
only in secure wrappers to prevent plaintext exposure of this 
information outside of SPU 500. 

The secure component based architecture of ROS 602 has 
important advantages. For example, it accommodates limited 
resource execution environments such as provided by a lower cost 
SPU 500. It also provides an extremely high level of 
configurability. In fact, ROS 602 will accommodate an almost 
unlimited diversity of content types, content provider objectives, 
transaction types and client requirements. In addition, the 
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ability to dynamically assemble independently deliverable 
components at execution time based on particular objects and 
users provides a high degree of flexibility, and facilitates or 
enables a distributed database, processing, and execution 
environment. 

One aspect of an advantage of the component-based 
architecture provided by ROS 602 relates to the ability to "stage" 
functionality and capabilities over time. As designed, 
implementation of ROS 602 is a finite task. Aspects of its wealth 
of functionality can remain unexploited until market realities 
dictate the implementation of corresponding VDE application 
functionality. As a result, initial product implementation 
investment and complexity may be limited. The process of 
"surfacing" the full range of capabilities provided by ROS 602 in 
terms of authoring, administrative, and artificial intelligence 
applications may take place over time. Moreover, already- 
designed functionality of ROS 602 may be changed or enhanced 
at any time to adapt to changing needs or requirements. 
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More Detailed Discussion of Rights Operating System 602 
Architecture 

Figure 12 shows an example of a detailed architecture of 
ROS 602 shown in Figure 10. ROS 602 may include a file system 
687 that includes a commercial database manager 730 and 
external object repositories 728. Commercial database manager 
730 may maintain secure database 610. Object repository 728 
may store, provide access to, and/or maintain VDE objects 300. 

Figure 12 also shows that ROS 602 may provide one or 
more SPEs 503 and/or one or more HPEs 655. As discussed 
above, HPE 655 may "emulate" an SPU 500 device, and such 
HPEs 655 may be integrated in lieu of (or in addition to) physical 
SPUs 500 for systems that need higher throughput. Some 
security may be lost since HPEs 655 are typically protected by 
operating system security and may not provide truly secure 
processing. Thus, in the preferred embodiment, for high security 
applications at least, all secure processing should take place 
within an SPE 503 having an execution space within a physical 
SPU 500 rather than a HPE 655 using software operating 
elsewhere in electronic appliance 600. 
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As mentioned above, three basic components of ROS 602 
are a kernel 680, a Remote Procedure Call (RPC) manager 732 
and an object switch 734. These components, and the way they 
interact with other portions of ROS 602, will be discussed below. 

Kernel 680 

Kernel 680 manages the basic hardware resources of 
electronic appliance 600, and controls the basic tasking provided 
by ROS 602. Kernel 680 in the preferred embodiment may 
include a memory manager 680a, a task manager 680b, and an 
I/O manager 680c. Task manager 680b may initiate and/or 
manage initiation of executable tasks and schedule them to be 
executed by a processor on which ROS 602 runs (e.g., CPU 654 
shown in Figure 8). For example, Task manager 680b may 
include or be associated with a "bootstrap loader" that loads other 
parts of ROS 602. Task manager 680b may manage all tasking 
related to ROS 602, including tasks associated with application 
program(s) 608. Memory manager 680a may manage allocation, 
deallocation, sharing and/or use of memory (e.g., RAM 656 shown 
in Figure 8) of electronic appliance 600, and may for example 
provide virtual memory capabilities as required by an electronic 
appliance and/or associated appKcation(s). I/O manager 680c 
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may manage all input to and output from ROS 602, and may 
interact with drivers and other hardware managers that provide 
communications and interactivity with physical devices. 

RPC Manager 732 

ROS 602 in a preferred embodiment is designed around a 
"services based* Remote Procedure Call architecture/interface. 
All functions performed by ROS 602 may use this common 
interface to request services and share information. For example, 
SPE(s) 503 provide processing for one or more RPC based 
services. In addition to supporting SPUs 500, the RPC interface 
permits the dynamic integration of external services and provides 
an array of configuration options using existing operating system 
components. ROS 602 also communicates with external services 
through the RPC interface to seamlessly provide distributed 
and/or remote processing. In smaller scale instances of ROS 602, 
a simpler message passing IPC protocol may be used to conserve 
resources. This may limit the configurability of ROS 602 
services, but this possible limitation may be acceptable in some 
electronic appliances. 
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The RPC structure allows services to be called/requested 
without the calling process having to know or specify where the 
service is physically provided, what system or device will service 
the request, or how the service request will be fulfilled. This 
feature supports families of services that may be scaled and/or 
customized for specific applications. Service requests can be 
forwarded and serviced by different processors and/or different 
sites as easily as they can be forwarded and serviced by a local 
service system. Since the same RPC interface is used by ROS 
602 in the preferred embodiment to request services within and 
outside of the operating system, a request for distributed and/or 
remote processing incurs substantially no additional operating 
system overhead. Remote processing is easily and simply 
integrated as part of the same service calls used by ROS 602 for 
requesting local-based services. In addition, the use of a 
standard RPC interface ("RSI") allows ROS 602 to be 
modularized, with the different modules presenting a 
standardized interface to the remainder of the operating system. 
Such modularization and standardized interfacing permits 
different vendors/operating system programmers to create 
different portions of the operating system independently, and 
also allows the functionality of ROS 602 to be flexibly updated 
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and/or changed based on different requirements and/or 
platforms. 

RPC manager 732 manages the RPC interface. It receives 
5 service requests in the form of one or more "Remote Procedure 

Calls" (RPCs) from a service requestor, and routes the service 
requests to a service providers) that can service the request. For 
example, when rights operating system 602 receives a request 
from a user application via user API 682, RPC manager 732 may 
10 route the service request to an appropriate service through the 

"RPC service interface" ("RSI"). The RSI is an interface between 
RPC manager 732, service requestors, and a resource that will 
accept and service requests. 

15 The RPC interface (RSI) is used for several major ROS 602 

subsystems in the preferred embodiment. 

RPC services provided by ROS 602 in the preferred 
embodiment are divided into subservices, i.e., individual 
20 instances of a specific service each of which may be tracked 

individually by the RPC manager 732. This mechanism permits 
multiple instances of a specific service on higher throughput 
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systems while maintaining a common interface across a spectrum 
of implementations. The subservice concept extends to 
supporting multiple processors, multiple SPEs 503, multiple 
HPEs 655, and multiple communications services. 

5 

The preferred embodiment ROS 602 provides the following 
RPC based service providers/requestors (each of which have an 
RPC interface or "RSF that communicates with RPC manager 
732): 

10 SPE device driver 736 (this SPE device driver is connected 

to an SPE 503 in the preferred embodiment); 
HPE Device Driver 738 (this HPE device driver is 
connected to an HPE 738 in the preferred 
embodiment); 

15 Notification Service 740 (this notification service is 

connected to user notification interface 686 in the 
preferred embodiment); 
API Service 742 (this API service is connected to user API 
682 in the preferred embodiment; 
20 Redirector 684; 

Secure Database (File) Manager 744 (this secure database 
or file manager 744 may connect to and interact with 
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commercial database manager 730 and secure files 
610 through a cache manager 746, a database 
interface 748, and a database driver 750); 

Name Services Manager 752; 

Outgoing Administrative Objects Manager 754; 

Incoming Administrative Objects Manager 756; 

a Gateway 734 to object switch 734 (this is a path used to 
allow direct communication between RPC manager 
732 and Object Switch 734); and 

Communications Manager 776. 

The types of services provided by HPE 655, SPE 503, User 
Notification 686, API 742 and Redirector 684 have already been 
described above. Here is a brief description of the type(s) of 
services provided by OS resources 744, 752, 754, 756 and 776: 

Secure Database Manager 744 services requests for access 

to secure database 610; 
Name ggrvjceg Manager 752 services requests relating tn 

user, host, or service identification; 
Outgoing Administrative Objects Manager 754 services 

requests relating to outgoing administrative objects; 
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T^pp ming AHmini strative Objects M fma gpr 7^fi services 

requests relating to incoming administrative objects; 
and 

nnmmnni cations Manager 776 services requests relating to 
communications between electronic appliance 600 
and the outside world. 

Object Switch 734 

Object switch 734 handles, controls and co mmu nicates 
(both locally and remotely) VDE objects 300. In the preferred 
embodiment, the object switch may include the following 
elements: 

a stream router 758; 

a real time stream interface(s) 760 (which may be 
connected to real time data feed(s) 694); 

a time dependent stream interface(s) 762; 

a intercept 692; 

a container manager 764; 

one or more routing tables 766; and 

buffering/storage 768. 
Stream router 758 routes to/from "real time" and "time 
independent" data streams handled respectively by real time 
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stream interface(s) 760 and time dependent stream interface(s) 
762. Intercept 692 intercepts I/O requests that involve real-time 
information streams such as, for example, real time feed 694. 
The routing performed by stream router 758 may be determined 
5 by routing tables 766. Buffering/storage 768 provides temporary 

store-and-forward, buffering and related services. Container 
manager 764 may (typically in conjunction with SPE 503) 
perform processes on VDE objects 300 such as constructing, 
deconstructing, and locating portions of objects. 

10 

Object switch 734 communicates through an Object Switch 
Interface COST) with other parts of ROS 602. The Object Switch 
Interface may resemble, for example, the interface for a Unix 
socket in the preferred embodiment. Each of the "OSF interfaces 
15 shown in Figure 12 have the ability to communicate with object 

switch 734. 

ROS 602 includes the following object switch service 
providers/resources (each of which can communicate with the 
20 object switch 734 through an "OSF): 

Outgoing Administrative Objects Manager 754; 
Incoming Administrative Objects Manager 756; 
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Gateway 734 (which may translate RPC calls into object 
switch calls and vice versa so RPC manager 732 may 
co mmuni cate with object switch 734 or any other 
element having an OSI to, for example, provide 
5 and/or request services); 

External Services Manager 772; 

Object Submittal Manager 774; and 

Communications Manager 776. 



10 Briefly, 

Object Repository Manager 770 provides services relating 

to access to object repository 728; 
External Serves Manager 772 provides services relating 
to requesting and receiving services externally, such 
15 as from a network resource or another site; 

Object Submittal Manager 774 provides services relating to 
how a user application may interact with object 
switch 734 (since the object submittal manager 
provides an interface to an application program 608, 
20 it could be considered part of user API 682); and 

r.^TmiTi ^ations Manager 776 provides services relating to 
communicating with the outside world. 
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In the preferred embodiment, communications manager 
776 may include a network manager 780 and a mail gateway 
(manager) 782. Mail gateway 782 may include one or more mail 
filters 784 to, for example, automatically route VDE related 
5 electronic mail between object switch 734 and the outside world 

electronic mail services. External Services Manager 772 may 
interface to co mmunic ations manager 776 through a Service 
Transport Layer 786. Service Transport Layer 786a may enable 
External Services Manager 772 to communicate with external 
10 computers and systems using various protocols managed using 

the service transport layer 786. 

The characteristics of and interfaces to the various 
subsystems of ROS 680 shown in Figure 12 are described in more 
15 detail below. 

RPC Manager 732 and Its RPC Services Interface 

As discussed above, the basic system services provided by 
ROS 602 are invoked by using an RPC service interface (RSI). 
20 This RPC service interface provides a generic, standardized 

interface for different services systems and subsystems provided 
by ROS 602. 
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RPC Manager 732 routes RPCs requesting services to an 
appropriate RPC service interface. In the preferred embodiment, 
upon receiving an RPC call, RPC manager 732 determines one or 
more service managers that are to service the request. RPC 
5 manager 732 then routes a service request to the appropriate 

service(s) (via a RSI associated with a service) for action by the 
appropriate service managers). 

For example, if a SPE 503 is to service a request, the RPC 
10 Manager 732 routes the request to RSI 736a, which passes the 

request on to SPE device driver 736 for forwarding to the SPE. 
Similarly, if HPE 655 is to service the request, RPC Manager 732 
routes the request to RSI 738a for forwarding to a HPE. In one 
preferred embodiment, SPE 503 and HPE 655 may perform 
15 essentially the same services so that RSIs 736a, 738a are 

different instances of the same RSI. Once a service request has 
been received by SPE 503 (or HPE 655), the SPE (or HPE) 
typically dispatches the request internally using its own internal 
RPC manager (as will be discussed shortly). Processes within 
20 SPEs 503 and HPEs 655 can also generate RPC requests. These 

requests may be processed internally by a SPE/HPE, or if not 
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internally serviceable, passed out of the SPE/HPE for dispatch by 
RPC Manager 732. 

Remote (and local) procedure calls may be dispatched by a 
5 RPC Manager 732 using an "RPC Services Table." An RPC 

Services Table describes where requests for specific services are 
to be routed for processing. Each row of an RPC Services Table 
in the preferred embodiment contains a services ID, the location 
of the service, and an address to which control will be passed to 

10 service a request. An RPC Services Table may also include 

control information that indicates which instance of the RPC 
dispatcher controls the service. Both RPC Manager 732 and any 
attached SPEs 503 and HPEs 655 may have symmetric copies of 
the RPC Services Table. If an RPC service is not found in the 

15 RPC services tables, it is either rejected or passed to external 

services manager 772 for remote servicing. 

Assuming RPC manager 732 finds a row corresponding to 
the request in an RPC Services Table, it may dispatch the . 
20 request to an appropriate RSI. The receiving RSI accepts a 

request from the RPC manager 732 (which may have looked up 
the request in an RPC service table), and processes that request 
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in accordance with internal priorities associated with the specific 
service- 
In the preferred embodiment, RPC Service Interface(s) 
5 supported by RPC Manager 732 may be standardized and 

published to support add-on service modules developed by third 
party vendors, and to facilitate scalability by making it easier to 
program ROS 602. The preferred embodiment RSI closely follows 
the DOS and Unix device driver models for block devices so that 
10 common code may be developed for many platforms with 

TrnniTrmm effort. An example of one possible set of common entry 
points are listed below in the table. 



" 20 



Interface call 


Description 


SVC LOAD 


Load a service manager and return its status. 


SVC UNLOAD 


Unload a service manager. 


SVC.MOUNT 


Mount (load) a dynamically loaded subservice and 
return its status. 


SVC UNMOUNT 


Unmount (unload) a dynamically loaded subservice. 


SVC_OPEN 


Open a mounted subservice. 


SVC_CLOSE 


Close a mounted subservice. 


SVC READ 


Read a block from an opened subservice. 
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SVC WRITE 


Write a block to an opened subservice. 


SVC IOCTL 


Control a subservice or a service manager. 



Load 

In the preferred embodiment, services (and the associated 
RSIs they present to RPC manager 732) may be activated during 
boot by an installation boot process that issues an RPC LOAD. 
This process reads an RPC Services Table from a configuration 
file, loads the service module if it is run time loadable (as opposed 
to being a kernel linked device driver), and then calls the LOAD 
entry point for the service. A successful return from the LOAD 
entry point will indicate that the service has properly loaded and 
is ready to accept requests. 

RPC LOAD Call Example: SVCJLOAD (long service_id) 

This LOAD interface call is called by the RPC manager 732 
during rights operating system 602 initialization. It permits a 
service manager to load any dynamically loadable components 
and to initialize any device and memory required by the service. 
The service number that the service is loaded as is passed in as 
service.id parameter. In the preferred embodiment, the service 
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returns 0 is the initialization process was completed successfully 
or an error number if some error occurred. 

Mount 

5 Once a service has been loaded, it may not be fully 

functional for all subservices. Some subservices (e.g., 
communications based services) may require the establishment of 
additional connections, or they may require additional modules to 
be loaded. If the service is defined as "mountable," a RPC 
10 manager 732 will call the MOUNT subservice entry point with 

the requested subservice ID prior to opening an instance of a 
subservice. 

RPC MOUNT Call Example: 

15 SVCJVIOUNT (long service_id, long subservice Jd, BYTE 

*buffer) 

This MOUNT interface call instructs a service to make a 
specific subservice ready. This may include services related to 
networking, communications, other system services, or external 
20 resources. The service _id and subservicejd parameters may be 

specific to the specific service being requested. The buffer 
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parameter is a memory address that references a control 
structure appropriate to a specific service. 

Open 

5 Once a service is loaded and "mounted," specific instances 

of a service may be "opened" for use. "Opening" an instance of a 
service may allocate memory to store control and status 
information. For example, in a BSD socket based network 
connection, a LOAD call will initialize the software and protocol 

10 control tables, a MOUNT call will specify networks and hardware 

resources, and an OPEN will actually open a socket to a remote 
installation. 

Some services, such as commercial database manager 730 
15 that underlies the secure database service, may not be 

"mountable." In this case, a LOAD call will make a connection to 
a database manager 730 and ensure that records are readable. 
An OPEN call may create instances of internal cache manager 
746 for various classes of records. 

20 

RPC OPEN Call Example: 

SVC.OPEN (long service Jd, long subservice _id, BYTE 
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♦buffer, int (^receive) (long request Jd)) 
This OPEN interface call instructs a service to open a 
specific subservice. The service_id and subservice_id 
parameters are specific to the specific service being requested, 
5 and the buffer parameter is a memory address that references a 

control structure appropriate to a specific service. 

The optional receive parameter is the address of a 
notification callback function that is called by a service whenever 
10 a message is ready for the service to retrieve it. One call to this 

address is made for each incoming message received. If the caller 
passes a NULL to the interface, the software will not generate a 
callback for each message. 

15 Close, Unmount and Unload 

The converse of the OPEN, MOUNT, and LOAD calls are 
CLOSE, UNMOUNT, and UNLOAD. These interface calls 
release any allocated resources back to ROS 602 (e.g., memory 
manager 680a). 

20 
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RPC CLOSE Call Example: SVC_CLOSE (long svcjiandle) 

This LOAD interface call closes an open service "handle." 
A service "handle" describes a service and subservice that a user 
wants to close. The call returns 0 if the CLOSE request succeeds 
(and the handle is no longer valid) or an error number. 

RPC UNLOAD Call Example: SVCJJNLOAD (void) 

This UNLOAD interface call is called by a EPC manager 
732 during shutdown or resource reallocation of rights operating 
system 602. It permits a service to close any open connections, 
flush buffers, and to release any operating system resources that 
it may have allocated. The service returns 0. 

RPC UNMOUNT Call Example: SVCJJNMOUNT (long 
service_id, long subservice_id) 

This UNMOUNT interface call instructs a service to 
deactivate a specific subservice. The service_id and 
subservice_id parameters are specific to the specific service 
being requested, and must have been previously mounted using 
the SVC_MOUNT() request. The call releases all system 
resources associated with the subservice before it returns. 
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Read and Write 

The READ and WRITE calls provide a basic mechanism for 
sending information to and receiving responses from a mounted 
and opened service. For example, a service has requests written 
to it in the form of an RPC request, and makes its response 
available to be read by RPC Manager 732 as they become 
available. 

RPC READ Call Example: 

SVC_READ (long svcjiandle, long requested, BYTE 
*buffer, long size) 

This READ call reads a message response from a service. 
The svcjiandle and requested parameters uniquely identify a 
request. The results of a request will be stored in the user 
specified buffer up to size bytes. If the buffer is too small, the 
first size bytes of the message will be stored in the buffer and an 
error will be returned. 

If a message response was returned to the caller's buffer 
correctly, the function will return 0. Otherwise, an error message 
will be returned. 
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RPC WHITE Call Example: 

SVC_write (long service Jd, long subservice Jd, BYTE 
*traffer, long size, int (^receive) (long requested) 

This WRITE call writes a message to a service and 
5 subservice specified by the service Jd/subservice_id parameter 

pair. The message is stored in buffer (and usually conforms to 
the VDE RPC message format) and is size bytes long. The 
function returns the request id for the message (if it was 
accepted for sending) or an error number. If a user specifies the 
10 receive callback functions, all messages regarding a request will 

be sent to the request specific callback routine instead of the 
generalized message callback. 

i 

Input/Output Control 

15 The IOCTL ("Inpu1/Output ConTroL") call provides a 

mechanism for querying the status of and controlling a loaded 
service. Each service type will respond to specific general IOCTL 
requests, all required class IOCTL requests, and service specific 
IOCTL requests. 

20 
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RPC IOCTL Call Example: ROI_SVC JOCTL (long sendee Jd, 
long subservice_id, 

int command, BYTE *buffer) 

5 This IOCTL function provides a generalized control 

interface for a RSL A user specifies the service_id parameter 
and an optional subservice_id parameter that they wish to 
control They specify the control command parameters), and a 
buffer into/from which the command parameters may be 
10 written/read. An example of a list of commands and the 

appropriate buffer structures are given below. 



1 

Command 


Structure 


Description 


GETJNFO 


SVCJNFO 


Returns information about a 
service/subservice. 


GET.STATS 


SVC.STATS 


Returns current statistics about a 
service/subservice. 


CLRJ3TATS 


None 


Clears the statistics about a 
service/subservice. 



20 ***** 

Now that a generic RPC Service Interface provided by the 
preferred embodiment has been described, the following 
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description relates to particular examples of services provided by 
ROS 602. 

SPE Device Driver 736 

5 SPE device driver 736 provides an interface between ROS 

602 and SPE 503. Since SPE 503 in the preferred embodiment 
runs within the confines of an SPU 500, one aspect of this device 
driver 736 is to provide low level communications services with 
the SPU 500 hardware. Another aspect of SPE device driver 736 
10 is to provide an RPC service interface (RSI) 736a particular to 

SPE 503 (this same RSI may be used to communicate with HPE 
655 through HPE device driver 738). 

SPE RSI 736a and driver 736 isolates calling processes 
15 within ROS 602 (or external to the ROS) from the detailed service 

provided by the SPE 503 by providing a set of basic interface 
points providing a concise function set. This has several 
advantages. For example, it permits a full line of scaled SPUs 
500 that all provide common functionality to the outside world 
20 but which may differ in detailed internal structure and 

architecture. SPU 500 characteristics such as the amount of 
memory resident in the device, processor speed, and the number 
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of services supported within SPU 500 may be the decision of the 
specific SPU manufacturer, and in any event may diflFer from one 
SPU configuration to another. To maintain compatibility, SPE 
device driver 736 and the RSI 736a it provides conform to a basic 
5 common RPC interface standard that "hides" differences between 

detailed configurations of SPUs 500 and/or the SPEs 503 they 
may support. 

To provide for such compatibility, SPE RSI 736a in the 
10 preferred embodiment follows a simple block based standard. In 

the preferred embodiment, an SPE RSI 736a may be modeled 
after the packet interfaces for network Ethernet cards. This 
standard closely models the block mode interface characteristics 
of SPUs 500 in the preferred embodiment. 

15 

An SPE RSI 736a allows RPC calls from RPC manager 732 
to access specific services provided by an SPE 736. To do this, 
SPE RSI 736a provides a set of "service notification address 
interfaces." These provide interfaces to individual services 
20 provided by SPE 503 to the outside world. Any calling process 

within ROS 602 may access these SPE-provided services by 
directing an RPC call to SPE RSI 736a and specifying a 
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corresponding "service notification address" in an RPC call. The 
specified "service notification address" causes SPE 503 to 
internally route an RPC call to a particular service within an 
SPE. The following is a listing of one example of a SPE service 
5 breakdown for which individual service notification addresses 

may be provided: 

Channel Services Manager 

Authentication Manager/Secure Communications Manager 
Secure Database Manager 

10 

The Channel Services Manager is the principal service 
provider and access point to SPE 503 for the rest of ROS 602. 
Event processing, as will be discussed later, is primarily 
managed (from the point of view of processes outside SPE 503) by 

15 this service. The Authentication Manager/Secure 

Communications Manager may provide login/logout services for 
users of ROS 602, and provide a direct service for managing 
communications (typically encrypted or otherwise protected) 
related to component assemblies 690, VDE objects 300, etc. 

20 Requests for display of information (e.g., value remaining in a 

financial budget) may be provided by a direct service request to a 
Secure Database Manager inside SPE 503. The instances of 
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Authentication Manager/Secure Communications Manager and 
Secure Database Manager, if available at all, may provide only a 
subset of the information and/or capabilities available to 
processes operating inside SPE 503. As stated above, most 
(potentially all) service requests entering SPE are routed to a 
Channel Services Manager for processing. As will be discussed in 
more detail later on, most control structures and event processing 
logic is associated with component assemblies 690 under the 
management of a Channel Services Manager. 

The SPE 503 must be accessed through its associated SPE 
driver 736 in this example. Generally, calls to SPE driver 736 
are made in response to RPC calls. In this example, SPE driver 
RSI 736a may translate RPC calls directed to control or ascertain 
information about SPE driver 736 into driver calls. SPE driver 
RSI 736a in conjunction with driver 736 may pass RPC calls 
directed to SPE 503 through to the SPE. 

The following table shows one example of SPE device 
driver 736 calls: 
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Entry Point 


Description 


1 


SPE_info() 


Returns summary information about the 
SPE driver 736 (and SPE 503) . 




SPE initialize interfaceO 


Initializes SPE driver 736, and sets the 
default notification address for received 
packets. 


5 


SPE_terminate_interface() 


Terminates SPE driver 736 and resets 
SPU 500 and the driver 736. 




SPE_reset_interface() 


Resets driver 736 without resetting SPU 
500. 




SPE_get_stats() 


Return statistics for notification 
addresses and/or an entire driver 736. 




SPE_clear_stats() 


Clears statistics for a specific 
notification address and/or an entire 
driver 736. 




SPE_set_notify() 


Sets a notification address for a specific 
service ID. 


10 


SPE_get_notify() 


Returns a notification address for a 
specific service ID. 




SPE_tx_pkt() 


Sends a packet (e.g., containing an RPC 
call) to SPE 503 for processing. 



The following are more detailed examples of each of the 
15 SPE driver calls set forth in the table above. 
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Example of an "SPE IxxformationT)river Call: SPEJnfo (void) 

This function returns a pointer to an SPEJNFO data 
structure that defines the SPE device driver 736a. This data 
structure may provide certain information about SPE device 
driver 736, RSI 736a and/or SPU 500. An example of a 
SPEJNFO structure is described below: 



10 



15 



Version Number/ID for SPE 
Device Driver 736 



Version Number/ID for SPE 
Device Driver RSI 736 



Pointer to name of SPE Device 
Driver 736 



Pointer to ID name of SPU 500 



Functionality Code Describing 
SPE Capabilities/functionality 



20 Example of an SPE Initialize InterfaceTDriver Call: 

SPE Jnitialize Jnterface (int (fen *receiver)(void)) 



A receiver function passed in by way of a parameter will be 
called for all packets received from SPE 503 unless their 
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destination service is over-ridden using the setjaotiiyO call. A 
receiver function allows ROS 602 to specify a format for packet 
communication between RPC manager 732 and SPE 503. 

5 This function returns "0" in the preferred embodiment if 

the initialization of the interface succeeds and non-zero if it fails. 
If the function fails, it will return a code that describes the reason 
for the failure as the value of the function. 



10 Example of an SPE 'Terminate InterfaceUriver Call: 

SPE_terminate_interface (void) 

In the preferred embodiment, this function shuts down 
SPE Driver 736, clears all notification addresses, and terminates 
all outst andin g requests between an SPE and an ROS RPC 
15 manager 732. It also resets an SPE 503 (e.g., by a warm reboot 

of SPU 500) after all requests are resolved. 

Termination of driver 736 should be performed by ROS 602 
when the operating system is starting to shut down. It may also 
20 be necessary to issue this call if an SPE 503 and ROS 602 get so 

far out of synchronization that all processing in an SPE must be 
reset to a known state. 
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Example of an SFE "Reset Interface*Driver Call: 

SPEjreset_interface (void) 

This function resets driver 736, terminates all outstanding 
5 requests between SPE 503 and an ROS RPC manager 732, and 

clears all statistics counts. It does not reset the SPU 500, but 
simply restores driver 736 to a known stable state. 

Example of an SPE "Get Statistics"Driver Call: SPE„get_stats 

10 (long service_id) 

This function returns statistics for a specific service 
notification interface or for the SPE driver 736 in general. It 
returns a pointer to a static buffer that contains these statistics 
or NULL if statistics are unavailable (either because an interface 

15 is not initialized or because a receiver address was not specified). 

An example of the SPE_STATS structure may have the following 
definition: 



20 



L 



Service id 



# packets rx 



# packets tx 



# bytes rx 



& hytea tv 
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# errors rx 



# errors tx 



# requests tx 



# req tx completed 



# req tx cancelled 



1 # req rx 
I # req rx < 
# req rx < 



# req rx completed 



# req rx cancelled 



10 



15 



20 



If a user specifies a service ID, statistics associated with 
packets sent by that service are returned. If a user specified 0 as 
the parameter, the total packet statistics for the interface are 
returned. 

Example of an SPE "Clear StatisticBTiriver Call: 

SPE_clear_stats (long service_id) 

This function clears statistics associated with the SPE 
service Jd specified. If no service_id is specified (i.e., the caller 
passes in 0), global statistics will be cleared. The function 
returns 0 if statistics are successfully cleared or an error number 
if an error occurs. 



i 
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Example of an SPE "Set Notification AddreBsDriver Call: 

SPE jset_notify (long service Jd, int (fcn*receiver) (void)) 

Tbis function sets a notification address (receiver) for a 
specified service. If the notification address is set to NULL, SPE 
5 device driver 736 will send notifications for packets to the 

specified service to the default notification address. 

Example of a SPE "Get Notification AddressT)river Call: 

SPE jjet_notify (long service_id) 
10 This function returns a notification address associated 

with the named service or NULL if no specific notification 
address has been specified. 

Example of an SPE "Send PacketfDriver Call: 

15 send_pkt (BYTE *buffer, long size, int (far ^receive) (void)) 

This function sends a packet stored in buffer of "length" 
size. It returns 0 if the packet is sent successfully, or returns an 
error code associated with the failure. 

20 Redirector Service Manager 684 

The redirector 684 is a piece of systems integration 
software used principally when ROS 602 is provided by "adding 
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on" to a pre-existing operating system or when "transparent" 
operation is desired for some VDE functions, as described earlier. 
In one embodiment the kernel 680, part of communications 
manager 776, file system 687, and part of API service 742 may be 
5 part of a pre-existing operating system such as DOS, Windows, 

UNIX, Macintosh System, OS9, PSOS, OS/2, or other operating 
system platform. The remainder of ROS 602 subsystems shown 
in Figure 12 may be provided as an "add on" to a preexisting 
operating system. Once these ROS subsystems have been 
10 supplied and "added on," the integrated whole comprises the ROS 

602 shown in Figure 12. 

In a scenario of this type of integration, ROS 602 will 
continue to be supported by a preexisting OS kernel 680, but may 
15 supplement (or even substitute) many of its functions by 

providing additional add-on pieces such as, for example, a virtual 
memory manager. 

Also in this integration scenario, an add-on portion of API 
20 service 742 that integrates readily with a preexisting API service 

is provided to support VDE function calls. A pre-existing API 
service integrated with an add-on portion supports an enhanced 
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set of operating system calls including both calls to VDE 
functions 604 and calls to functions 606 other than VDE 
functions (see Figure 11A). The add-on portion of API service 
742 may translate VDE function calls into RPG calls for routing 
by RPC manager 732. 

ROS 602 may use a standard communications manager 
776 provided by the preexisting operating system, or it may 
provide "add ons" and/or substitutions to it that may be readily 
integrated into it. Redirector 684 may provide this integration 
function. 

This leaves a requirement for ROS 602 to integrate with a 
preexisting file system 687. Redirector 684 provides this 
integration function. 

In this integration scenario, file system 687 of the 
preexisting operating system is used for all accesses to secondary 
storage. However, VDE objects 300 may be stored on secondary 
storage in the form of external object repository 728, file system 
687, or remotely accessible through communications manager 
776. When object switch 734 wants to access external object 
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repository 728, it makes a request to the object repository 
manager 770 that then routes the request to object repository 728 
or to redirector 692 (which in turn accesses the object in file 
system 687). 

5 

Generally, redirector 684 maps VDE object repository 728 
content into preexisting calls to file system 687. The redirector 
684 provides preexisting OS level information about a VDE object 
300, including mapping the object into a preexisting OS's name 
10 space. This permits seamless access to VDE protected content 

using "normal" file system 687 access techniques provided by a 
preexisting operating system. 

In the integration scenarios discussed above, each 
15 preexisting target OS file system 687 has different interface 

requirements by which the redirector mechanism 684 may be 
"hooked." In general, since all commercially viable operating 
systems today provide support for network based volumes, file 
systems, and other devices (e.g., printers, modems, etc.), the 
20 redirector 684 may use low level network and file access "hooks" 

to integrate with a preexisting operating system. "Add-ons" for 
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supporting VDE functions 602 may use these existing hooks to 
integrate with a preexisting operating system. 

User Notification Service Manager 740 

5 User Notification Service Manager 740 and associated user 

notification exception interface ("pop up") 686 provides ROS 602 
with an enhanced ability to co mmunic ate with a user of electronic 
appliance 600. Not all applications 608 may be designed to 
respond to messaging from ROS 602 passed through API 682, 

10 and it may in any event be important or desirable to give ROS 

602 the ability to co mmunic ate with a user no matter what state 
an application is in. User notification services manager 740 and 
interface 686 provides ROS 602 with a mechanism to 
communicate directly with a user, instead of or in addition to 

15 passing a return call through API 682 and an application 608. 

This is similar, for example, to the ability of the Windows 
operating system to display a user message in a "dialog box" that 
displays "on top of a running application irrespective of the state 
of the application. 



20 



The User Notification 686 block in the preferred 
embodiment may be implemented as application code. The 
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implementation of interface 740a is preferably built over 
notification service manager 740, which may be implemented as 
part of API service manager 742. Notification services manager 
740 in the preferred embodiment provides notification support to 
5 dispatch specific notifications to an appropriate user process via 

the appropriate API return, or by another path. This mechanism 
permits notifications to be routed to any authorized process — not 
just back to a process that specified a notification mechanism, 

10 API Service Manager 742 

The preferred embodiment API Service Manager 742 is 
implemented as a service interface to the RPC service manager 
732. All user API requests are built on top of this basic interface. 
The API Service Manager 742 preferably provides a service 
15 instance for each running user application 608. 

Most RPC calls to ROS functions supported by API Service 
Manager 742 in the preferred embodiment may map directly to 
service calls with some additional parameter checking. This 
20 mechanism permits developers to create their own extended API 

libraries with additional or changed functionality. 
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In the scenario discussed above in which ROS 602 is 
formed by integrating "add ons" with a preexisting operating 
system, the API service 742 code may be shared (e.g., resident in 
a host environment like a Windows DLL), or it may be directly 
5 linked with an applications^ code— depending on an application 

programmer's implementation decision, and/or the type of 
electronic appliance 600. The Notification Service Manager 740 
may be implemented within API 682. These components 
interface with Notification Service component 686 to provide a 
10 transition between system and user space. 

Secure Database Service Manager CSDSM) 744 

There are at least two ways that may be used for managing 
secure database 600: 
15 C a commercial database approach, and 

C a site record number approach. 

Which way is chosen may be based on the number of records that 
a VDE site stores in the secure database 610. 

20 The commercial database approach uses a commercial 

database to store securely wrappered records in a commercial 
database. This way may be preferred when there are a large 
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number of records that are stored in the secure database 610. 
This way provides high speed access, efficient updates, and easy 
integration to host systems at the cost of resource usage (most 
commercial database managers use many system resources). 

The site record number approach uses a "site record 
number" ("SRN") to locate records in the system. This scheme is 
preferred when the number of records stored in the secure 
database 610 is small and is not expected to change extensively 
over time. This way provides efficient resources use with limited 
update capabilities. SRNs permit further grouping of similar 
data records to speed access and increase performance. 

Since VDE 100 is highly scalable, different electronic 
15 appliances 600 may suggest one way more than the other. For 

example, in limited environments like a set top, PDA, or other 
low end electronic appliance, the SRN scheme may be preferred 
because it limits the amount of resources (memory and processor) 
required. When VDE is deployed on more capable electronic 
20 appliances 600 such as desktop computers, servers and at 

clearinghouses, the commercial database scheme may be more 



5 



10 
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desirable because it provides high performance in environments 
where resources are not limited. 

One difference between the database records in the two 
5 approaches is whether the records are specified using a full VDE 

ID or SRN. To translate between the two schemes, a SRN 
reference may be replaced with a VDE ID database reference 
wherever it occurs. Similarly, VDE IDs that are used as indices 
or references to other items may be replaced by the appropriate 
10 SRN value. 

In the preferred embodiment, a commercially available 
database manager 730 is used to maintain secure database 610. 
ROS 602 interacts with commercial database manager 730 
15 through a database driver 750 and a database interface 748. The 

database interface 748 between ROS 602 and external, third 
party database vendors' commercial database manager 730 may 
be an open standard to permit any database vendor to implement 
a VDE compliant database driver 750 for their products. 

20 

ROS 602 may encrypt each secure database 610 record so 
that a VDE-provided security layer is "on top of" the commercial 
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database structure. In other words, SPE 736 may write secure 
records in sizes and formats that may be stored within a 
database record structure supported by commercial database 
manager 730. Commercial database manager 730 may then be 
used to organize, store, and retrieve the records. In some 
embodiments, it may be desirable to use a proprietary and/or 
newly created database manager in place of commercial database 
manager 730. However, the use of commercial database manager 
730 may provide certain advantages such as, for example, an 
ability to use already existing database management produces). 

The Secure Database Services Manager ("SDSM") 744 
makes calls to an underlying commercial database manager 730 
to obtain, modify, and store records in secure database 610. In 
the preferred embodiment, "SDSM" 744 provides a layer "on top 
of the structure of commercial database manager 730. For 
example, all VDE-secure information is sent to commercial 
database manager 730 in encrypted form. SDSM 744 in 
conjunction with cache manager 746 and database interface 748 
may provide record management, caching (using cache manager 
746), and related services (on top of) commercial database 
systems 730 and/or record managers. Database Interface 748 
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and cache manager 746 in the preferred embodiment do not 
present their own RSI, but rather the RPC Manager 732 
communicates to them through the Secure Database Manager 
RSI 744a. 

Name Services Manager 752 

The Name Services Manager 752 supports three 
subservices: user name services, host name services, and 
services name services. User name services provides mapping 
and lookup between user name and user ED numbers, and may 
also support other aspects of user-based resource and information 
security. Host name services provides mapping and lookup 
between the names (and other information, such as for example 
address, communications connection/routing information, etc.) of 
other processing resources (e.g., other host electronic appliances) 
and VDE node IDs. Services name service provides a mapping 
and lookup between services names and other pertinent 
information such as connection information (e.g., remotely 
available service routing and contact information) and_ service 
IDs. 
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Name Services Manager 752 in the preferred embodiment 
is connected to External Services Manager 772 so that it may 
provide external service routing information directly to the 
external services manager. Name services manager 752 is also 
connected to secure database manager 744 to permit the name 
services manager 752 to access name services records stored 
within secure database 610. 

External Services Manager 772 & Services Transport Layer 786 

The External Services Manager 772 provides protocol 
support capabilities to interface to external service providers. 
External services manager 772 may, for example, obtain external 
service routing information from name services manager 752, 
and then initiate contact to a particular external service (e.g., 
another VDE electronic appliance 600, a financial clearinghouse, 
etc.) through communications manager 776. External services 
manager 772 uses a service transport layer 786 to supply 
communications protocols and other information necessary to 
provide communications. 

There are several important examples of the use of 
External Services Manager 772. Some VDE objects may have 
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some or all of their content stored at an Object Repository 728 on 
an electronic appliance 600 other than the one operated by a user 
who has, or wishes to obtain, some usage rights to such VDE 
objects. In this case, External Services Manager 772 may 
5 manage a connection to the electronic appliance 600 where the 

VDE objects desired (or their content) is stored. In addition, file 
system 687 may be a network file system (e.g., Netware, 
LANtastic, NFS, etc.) that allows access to VDE objects using 
redirecter 684. Object switch 734 also supports this capability. 

10 

If External Services Manager 772 is used to access VDE 
objects, many different techniques are possible. For example, the 
VDE objects may be formatted for use with the World Wide Web 
protocols (HTML, HTTP, and URL) by including relevant 
15 headers, content tags, host ID to URL conversion (e.g., using 

Name Services Manager 752) and an HTTP-aware instance of 
Services Transport Layer 786. 

In other examples, External Services Manager 772 may be 
20 used to locate, connect to, and utilize remote event processing 

services; smart agent execution services (both to provide these 
services and locate them); certification services for Public Keys; 
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remote Name Services; and other remote functions either 
supported by ROS 602 RPCs (e.g., have RSIs), or using protocols 
supported by Services Transport Layer 786. 

5 Outgoing Administrative Object Manager 754 

Outgoing administrative object manager 754 receives 
administrative objects from object switch 734, object repository 
manager 770 or other source for transmission to another VDE 
electronic appliance. Outgoing administrative object manager 

10 754 takes care of sending the outgoing object to its proper 

destination. Outgoing administrative object manager 754 may 
obtain routing information from name services manager 752, and 
may use com munic ations service 776 to send the object. 
Outgoing administrative object manager 754 typically maintains 

15 records (in concert with SPE 503) in secure database 610 (e.g., 

shipping table 444) that reflect when objects have been 
successfully transmitted, when an object should be transmitted, 
and other information related to transmission of objects. 

20 Incoming Administrative Object Manager 756 

.» 

Incoming administrative object manager 756 receives 
administrative objects from other VDE electronic appliances 600 
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via co mmunic ations manager 776. It may route the object to 
object repository manager 770, object switch 734 or other 
destination. Inco ming administrative object manager 756 
typically maintains records (in concert with SPE 503) in secure 
5 database 610 (e.g., receiving table 446) that record which objects 

have been received, objects expected for receipt, and other 
information related to received and/or expected objects. 

Object Repository Manager 770 

10 Object repository manager 770 is a form of database or file 

manager. It manages the storage of VDE objects 300 in object 
repository 728, in a database, or in the file system 687. Object 
repository manager 770 may also provide the ability to browse 
and/or search information related to objects (such as summaries 

15 of content, abstracts, reviewers' commentary, schedules, 

promotional materials, etc.), for example, by using 
INFORMATION methods associated with VDE objects 300. 

Object Submittal Manager 774 

20 Object submittal manager 774 in the preferred 

embodiment provides an interface between an application 608 
and object switch 734, and thus may be considered in some 
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respects part of API 682. For example, it may allow a user 
application to create new VDE objects 300. It may also allow 
incoming/outgoing administrative object managers 756, 754 to 
create VDE objects 300 (administrative objects). 

Figure 12A shows how object submittal manager 774 may 
be used to communicate with a user of electronic appliance 600 to 
help to create a new VDE object 300. Figure 12A shows that 
object creation may occur in two stages in the preferred 
embodiment: an object definition stage 1220, and an object 
creation stage 1230. The role of object submittal manager 774 is 
indicated by the two different "user input* depictions (774(1), 
774(2)) shown in Figure 12A. 

In one of its roles or instances, object submittal manager 
774 provides a user interface 774a that allows the user to create 
an object configuration file 1240 specifying certain characteristics 
of a VDE object 300 to be created. This user interface 774a may, 
for example, allow the user to specify that she wants to create an 
object, allow the user to designate the content the object will 
contain, and allow the user to specify certain other aspects of the 
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information to be contained within the object (e.g., rules and 
control information, identifying information, etc.). 

Part of the object definition task 1220 in the preferred 
5 embodiment may be to analyze the content or other information 

to be placed within an object. Object definition user interface 
774a may issue calls to object switch 734 to analyze "content" or 
other information that is to be included within the object to be 
created in order to define or organize the content into "atomic 

10 elements" specified by the user. As explained elsewhere herein, 

such "atomic element" organizations might, for example, break 
up the content into paragraphs, pages or other subdivisions 
specified by the user, and might be explicit (e.g., inserting a 
control character between each "atomic element") or implicit. 

15 Object switch 734 may receive static and dynamic content (e.g., 

by way of time independent stream interface 762 and real time 
stream interface 760), and is capable of accessing and retrieving 
stored content or other information stored within file system 687. 

20 The result of object definition 1240 may be an object 

configuration file 1240 specifying certain parameters relating to 
the object to be created. Such parameters may include, for 
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example, map tables, key management specifications, and event 
method parameters. The object construction stage 1230 may 
take the object configuration file 1240 and the information or 
content to be included within the new object as input, construct 
5 an object based on these inputs, and store the object within object 

repository 728. 

Object construction stage 1230 may use information in 
object configuration file 1240 to assemble or modify a container. 
10 This process typically involves communicating a series of events 

to SPE 503 to create one or more PERCs 808, public headers, 
private headers, and to encrypt content, all for storage in the new 
object 300 (or within secure database 610 within records 
associated with the new object). 

15 

The object configuration file 1240 may be passed to 
container manager 764 within object switch 734. Container 
manager 734 is responsible for constructing an object 300 based 
on the object configuration file 1240 and further user input. The 
20 user may interact with the object construction 1230 through 

another instance 774(2) of object submittal manager 774. In this 
further user interaction provided by object submittal manager 
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774, the user may specify permissions, rules and/or control 
information to be applied to or associated with the new object 
300. To specify permissions, rules and control information, object 
submittal manager 774 and/or container manager 764 within 
5 object switch 734 generally will, as mentioned above, need to 

issue calls to SPE 503 (e.g., through gateway 734) to cause the 
SPE to obtain appropriate information from secure database 610, 
generate appropriate database items, and store the database 
items into the secure database 610 and/or provide them in 

10 encrypted, protected form to the object switch for incorporation 

into the object. Such information provided by SPE 503 may 
include, in addition to encrypted content or other information, 
one or more PERCs 808, one or more method cores 1000', one or 
more load modules 1100, one or more data structures such as 

15 UDEs 1200 and/or MDEs 1202, along with various key blocks, 

tags, public and private headers, and error correction 
information. 

The container manager 764 may, in cooperation with SPE 
20 503, construct an object container 302 based at least in part on 

parameters about new object content or other information as 
specified by object configuration file 1240. Container manager 
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764 may then insert into the container 302 the content or other 
information (as encrypted by SPE 503) to be included in the new 
object. Container manager 764 may also insert appropriate 
permissions, rules and/or control information into the container 
5 302 (this permissions, rules and/or control information may be 

defined at least in part by user interaction through object 
submittal manager 774, and may be processed at least in part by 
SPE 503 to create secure data control structures). Container 
manager 764 may then write the new object to object repository 
10 687, and the user or the electronic appliance may "register" the 

new object by including appropriate information within secure 
database 610. 

Communications Subsystem 776 

15 Communications subsystem 776, as discussed above, may 

be a conventional co mmunic ations service that provides a 
network manager 780 and a mail gateway manager 782. Mail 
filters 784 may be provided to automatically route objects 300 
and other VDE information to/from the outside world. 

20 Communications subsystem 776 may support a real time content 

feed 684 from a cable, satellite or other telecommunications link. 
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Secure Processing Environment 503 

As discussed above in connection with Figure 12, each 
electronic appliance 600 in the preferred embodiment includes 
one or more SPEs 503 and/or one or more HPEs 655. These 
5 secure processing environments each provide a protected 

execution space for performing tasks in a secure manner. They 
may fulfill service requests passed to them by ROS 602, and they 
may themselves generate service requests to be satisfied by other 
services within ROS 602 or by services provided by another VDE 
10 electronic appliance 600 or computer. 

In the preferred embodiment, an SPE 503 is supported by 
the hardware resources of an SPU 500. An HPE 655 may be 
supported by general purpose processor resources and rely on 

15 software techniques for security/protection. HPE 655 thus gives 

ROS 602 the capability of assembling and executing certain 
component assemblies 690 on a general purpose CPU such as a 
microcomputer, minicomputer, mainframe computer or 
supercomputer processor. In the preferred embodiment, the 

20 overall software architecture of an SPE 503 may be the same as 

the software architecture of an HPE 655. An HPE 655 can 
"emulate* SPE 503 and associated SPU 500, Le., each may 
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include services and resources needed to support an identical set 
of service requests from ROS 602 (although ROS 602 may be 
restricted from sending to an HOPE certain highly secure tasks to 
be executed only within an SPU 500). 

Some electronic appliance 600 configurations might include 
both an SPE 503 and an HPE 655. For example, the HPE 655 
could perform tasks that need lesser (or no) security protections, 
and the SPE 503 could perform all tasks that require a high 
degree of security. This ability to provide serial or concurrent 
processing using multiple SPE and/or HPE arrangements 
provides additional flexibility, and may overcome limitations 
imposed by limited resources that can practically or cost- 
effectively be provided within an SPU 500. The cooperation of 
an SPE 503 and an HPE 655 may, in a particular application, 
lead to a more efficient and cost effective but nevertheless secure 
overall processing environment for supporting and providing the 
secure processing required by VDE 100. As one example, an 
HPE 655 could provide overall processing for allowing a user to 
manipulate released object 300 'contents/ but use SPE 503 to 
access the secure object and release the information from the 
object. 
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Figure 13 shows the software architecture of the preferred 
embodiment Secure Processing Environment (SPE) 503. This 
architecture may also apply to the preferred embodiment Host 
Processing Environment (HPE) 655. "Protected Processing 
Environment" (TPE") 650 may refer generally to SPE 503 and/or 
HPE 655. Hereinafter, unless context indicates otherwise, 
references to any of "PPE 650," "HPE 655" and "SPE 503" may 
refer to each of them. 

As shown in Figure 13, SPE 503 (PPE 650) includes the 
following service managers/major functional blocks in the 
preferred embodiment: 
Kernel/Dispatcher 552 
C Channel Services Manager 562 
C SPE RPC Manager 550 
C Time Base Manager 554 
C Encryption/Decryption Manager 556 
C Key and Tag Manager 558 
C Summary Services Manager 560 
C Authentication Manager/Service Communications 

Manager 564 
C Random Value Generator 565 
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C Secure Database Manager 566 
C Other Services 592. 

Each of the major functional blocks of PPE 650 is discussed 
5 in detail below. 



I. SPE Kernel/Dispatcher 552 

The Kernel/Dispatcher 552 provides an operating system 
"kernel" that runs on and manages the hardware resources of 

10 SPU 500. This operating system "kernel" 552 provides a self- 

contained operating system for SPU 500; it is also a part of 
overall ROS 602 (which may include multiple OS kernels, 
including one for each SPE and HPE ROS is 
controlling/managing). Kernel/dispatcher 552 provides SPU task 

15 and memory management, supports internal SPU hardware 

interrupts, provides certain "low level services," manages "DTD" 
data structures, and manages the SPU bus interface unit 530. 
Kernel/dispatcher 552 also includes a load module execution 
manager 568 that can load programs into secure execution space 

20 for execution by SPU 500. 
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In the preferred embodiment, kernel/dispatcher 552 may 
include the following software/functional components: 
load module execution manager 568 
task manager 576 
5 memory manager 578 

virtual memory manager 580 
'low level" services manager 582 
internal interrupt handlers 584 
BIU handler 586 (may not be present in HPE 655) 
10 Service interrupt queues 588 

DTD Interpreter 590. 

At least parts of the kernel/dispatcher 552 are preferably 
stored in SPU firmware loaded into SPU ROM 532. An example 

15 of a memory map of SPU ROM 532 is shown in Figure 14A. This 

memory map shows the various components of kernel/dispatcher 
552 (as well as the other SPE services shown in Figure 13) 
residing in SPU ROM 532a and/or EEPROM 532b. The Figure 
14B example of an NVRAM 534b memory map shows the task 

20 manager 576 and other information loaded into NVRAM. 
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One of the functions performed by kernel/dispatcher 552 is 
to receive RPC calls from ROS RPC manager 732. As explained 
above, the ROS Kernel RPC manager 732 can route RPC calls to 
the SPE 503 (via SPE Device Driver 736 and its associated RSI 
5 736a) for action by the SPE. The SPE kernel/dispatcher 552 

receives these calls and either handles them or passes them on to 
SPE RPC manager 550 for routing internally to SPE 503. SPE 
503 based processes can also generate RPC requests. Some of 
these requests can be processed internally by the SPE 503. If 
10 they are not internally serviceable, they may be passed out of the 

SPE 503 through SPE kernel/dispatcher 552 to ROS RPC 
manager 732 for routing to services external to SPE 503. 

A. Kernel/Dispatcher Task Management 

15 Kernel/dispatcher task manager 576 schedules and 

oversees tasks executing within SPE 503 (PPE 650). SPE 503 
supports many types of tasks. A "channel" (a special type of task 
that controls execution of component assemblies 690 in the 
preferred embodiment) is treated by task manager 576 as one 

20 type of task. Tasks are submitted to the task manager 576 for 

execution. Task manager 576 in turn ensures that the SPE 
503/SPU 500 resources necessary to execute the tasks are made 
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available, and then arranges for the SPU microprocessor 520 to 
execute the task. 

Any call to kernel/dispatcher 552 gives the kernel an 
opportunity to take control of SPE 503 and to change the task or 
tasks that are currently executing. Thus, in the preferred 
embodiment kernel/dispatcher task manager 576 may (in 
conjunction with virtual memory manager 580 and/or memory 
manager 578) "swap out" of the execution space any or all of the 
tasks that are currently active, and "swap in" additional or 
different tasks. 

SPE tasking managed by task manager 576 may be either 
"single ta sking " (meaning that only one task may be active at a 
15 time) or "multi-tasking" (me anin g that multiple tasks may be 

active at once). SPE 503 may support single tasking or multi- 
tasking in the preferred embodiment. For example, "high end" 
implementations of SPE 503 (e.g., in server devices) should 
preferably include multi-tasking with "preemptive scheduling." 
20 Desktop applications may be able to use a simpler SPE 503, 

although they may still require concurrent execution of several 
tasks. Set top applications may be able to use a relatively simple 
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implementation of SPE 503, supporting execution of only one 
task at a time. For example, a typical set top implementation of 
SPU 500 may perform simple metering, budgeting and billing 
using subsets of VDE methods combined into single "aggregate" 
5 load modules to permit the various methods to execute in a single 

t asking environment. However, an execution environment that 
supports only single tasking may limit use with more complex 
control structures. Such single tasking versions of SPE 503 trade 
flexibility in the number and types of metering and budgeting 

10 operations for smaller run time RAM size requirements. Such 

implementations of SPE 503 may (depending upon memory 
limit ations) also be limited to metering a single object 300 at a 
time. Of course, variations or combinations are possible to 
increase capabilities beyond a simple single tasking environment 

15 without incurring the additional cost required to support "full 

multitasking." 

In the preferred embodiment, each task in SPE 503 is 
represented by a "swap block," which may be considered a "task" 
20 in a traditional multitasking architecture. A "swap block" in the 

preferred embodiment is a bookkeeping mechanism used by task 
manager 576 to keep track of tasks and subtasks. It corresponds 
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to a ch unk of code and associated references that "fits" within the 
secure execution environment provided by SPU 500. In the 
preferred embodiment, it contains a list of references to shared 
data elements (e.g., load modules 1100 and UDEs 1200), private 
5 data elements (e.g., method data and local stack), and swapped 

process "context" information (e.g., the register set for the process 
when it is not processing). Figure 14C shows an example of a 
snapshot of SPU RAM 532 storing several examples of "swap 
blocks" for a number of different tasks/methods such as a 

10 "channel" task, a "control" task, an "event" task, a "meter" task, a 

"budget" task, and a "b illing " task. Depending on the size of SPU 
RAM 532, "swap blocks" may be swapped out of RAM and stored 
temporarily on secondary storage 652 until their execution can be 
continued. Thus, SPE 503 operating in a multi-tasking mode 

15 may have one or more tasks "sleeping." In the simplest form, this 

involves an active task that is currently processing, and another 
task (e.g., a control task under which the active task may be 
running) that is "sleeping" and is "swapped out" of active 
execution space. Kernel/dispatcher 522 may swap out tasks at 

20 any time. 
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Task manager 576 may use Memory Manager 578 to help 
it perform this swapping operation. Tasks may be swapped out of 
the secure execution space by reading appropriate information 
from RAM and other storage internal to SPU 500, for example, 
5 and writing a "swap block" to secondary storage 652. Kernel 552 

may swap a task back into the secure execution space by reading 
the swap block from secondary storage 652 and writing the 
appropriate information back into SPU RAM 532. Because 
secondary storage 652 is not secure, SPE 503 must encrypt and 

10 cryptographically seal (e.g., using a one-way hash function 

initialized with a secret value known only inside the SPU 500) 
each swap block before it writes it to secondary storage. The SPE 
503 must decrypt and verify the cryptographic seal for each swap 
block read from secondary storage 652 before the swap block can 

15 be returned to the secure execution space for further execution. 

Loa ding a "swap block" into SPU memory may require one 
or more "paging operations" to possibly first save, and then flush, 
any "dirty pages" (i.e., pages changed by SPE 503) associated 
20 with the previously loaded swap blocks, and to load all required 

pages for the new swap block context. 
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Kernel/dispatcher 522 preferably manages the "swap 
blocks" using service interrupt queues 588. These service 
interrupt queues 588 allow kernel/dispatcher 552 to track tasks 
(swap blocks) and their status (running, "swapped out," or 
5 "asleep"). The kernel/dispatcher 552 in the preferred 

embodiment may maintain the following service interrupt queues 
588 to help it manage the "swap blocks": 
RUN queue 
SWAP queue 
10 SLEEP queue. 

Those tasks that are completely loaded in the execution space 
and are waiting for and/or using execution cycles from 
microprocessor 502 are in the RUN queue. Those tasks that are 
"swapped" out (e.g., because they are waiting for other swappable 
15 components to be loaded) are referenced in the SWAP queue. 

Those tasks that are "asleep" (e.g., because they are "blocked" on 
some resource other than processor cycles or are not needed at 
the moment) are referenced in the SLEEP queue. 
Kernel/dispatcher task manager 576 may, for example, transition 
20 tasks between the RUN and SWAP queues based upon a "round- 

robin" scheduling algorithm that selects the next task waiting for 
service, swaps in any pieces that need to be paged in, and 
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executes the task. Kernel/dispatcher 552 task manager 576 may 
transition tasks between the SLEEP queue and the "awake" (i.e., 
RUN or SWAP) queues as needed. 

5 When two or more tasks try to write to the same data 

structure in a multi-tasking environment, a situation exists that 
may result in "deadly embrace" or "task starvation." A "multi- 
threaded" tasking arrangement may be used to prevent "deadly 
embrace" or "task starvation" from happening. The preferred 
10 embodiment kernel/dispatcher 552 may support "single threaded" 

or "multi-threaded" tasking. 

In single threaded applications, the kernel/dispatcher 552 
"locks" individual data structures as they are loaded. Once 

15 locked, no other SPE 503 task may load them and will "block" 

waiting for the data structure to become available. Using a 
single threaded SPE 503 may, as a practical matter, limit the 
ability of outside vendors to create load modules 1100 since there 
can be no assurance that they will not cause a "deadly embrace" 

20 with other VDE processes about which outside vendors may 

know little or nothing. Moreover, the context swapping of a 
partially updated record might destroy the integrity of the 
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system, permit unmetered use, and/or lead to deadlock. In 
addition, such "locking" imposes a potentially indeterminate 
delay into a typically time critical process, may limit SPE 503 
throughput, and may increase overhead. 

5 

This issue notwithstanding, there are other significant 
processing issues related to building single-threaded versions of 
SPE 503 that may limit its usefulness or capabilities under some 
circumstances. For example, multiple concurrently executing 

10 tasks may not be able to process using the same often-needed 

data structure in a single-threaded SPE 503. This may 
effectively limit the number of concurrent tasks to one. 
Additionally, single-threadedness may eliminate the capability of 
producing accurate summary budgets based on a number of 

15 concurrent tasks since multiple concurrent tasks may not be able 

to effectively share the same summary budget data structure. 
Single-threadedness may also eliminate the capability to support 
audit processing concurrently with other processing. For 
example, real-time feed processing might have to be shut down in 

20 order to audit budgets and meters associated with the monitoring 

process. 
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One way to provide a more workable "single-threaded" 
capability is for kernel/dispatcher 552 to use virtual page 
handling algorithms to track "dirty pages" as data areas are 
written to. The "dirty pages" can be swapped in and out with the 
5 task swap block as part of local data associated with the swap 

block. When a task exits, the "dirty pages" can be merged with 
the current data structure (possibly updated by another task for 
SPU 500) using a three-way merge algorithm (i.e., merging the 
original data structure, the current data structure, and the "dirty 

10 pages" to form a new current data structure). During the update 

process, the data structure can be locked as the pages are 
compared and swapped. Even though this virtual paging solution 
might be workable for allowing single threading in some 
applications, the vendor limitations mentioned above may limit 

15 the use of such single threaded implementations in some cases to 

dedicated hardware. Any implementation that supports multiple 
users (e.g., "smart home" set tops, many desk tops and certain 
PDA applications, etc.) may hit limitations of a single threaded 
device in certain circumstances. 

20 

It is preferable when these limitations are unacceptable to 
use a full "multi-threaded" data structure write capabilities. For 
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example, a type of "two-phase commit" processing of the type 
used by database vendors may be used to allow data structure 
sharing between processes. To implement this "two-phase 
commit" process, each swap block may contain page addresses for 
5 additional memory blocks that will be used to store changed 

information. A change page is a local copy of a piece of a data 
element that has been written by an SPE process. The changed 
page(s) references associated with a specific data structure are 
stored locally to the swap block in the preferred embodiment. 

10 

For example, SPE 503 may support two (change pages) per 
data structure. This limit is easily alterable by changing the size 
of the swap block structure and allowing the update algorithm to 
process all of the changed pages. The "commit" process can be 

15 invoked when a swap block that references changed pages is 

about to be discarded. The commit process takes the original 
data element that was originally loaded (e.g., UDEq), the current 
data element (e.g., UDE n ) and the changed pages, and merges 
them to create a new copy of the data element (e.g., UDE n+ ^). 

20 Differences can be resolved by the DTD interpreter 590 using a 

DTD for the data element. The original data element is 
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discarded (e.g., as determined by its DTD use count) if no other 
swap block references it. 

B. Kernel/Dispatcher Memory Management 

5 Memory manager 578 and virtual memory manager 580 in 

the preferred embodiment manage ROM 532 and RAM 534 
memory within SPU 500 in the preferred embodiment. Virtual 
memory manager 580 provides a fully "virtual" memory system to 
increase the amount of "virtual" RAM available in the SPE 

10 secure execution space beyond the amount of physical RAM 534a 

provided by SPU 500. Memory manager 578 manages the 
memory in the secure execution space, controlling how it is 
accessed, allocated and deallocated. SPU MMU 540, if present, 
supports virtual memory manager 580 and memory manager 578 

15 in the preferred embodiment. In some "minimal" configurations 

of SPU 500 there may be no virtual memory capability and all 
memory management functions will be handled by memory 
manager 578. Memory management can also be used to help 
enforce the security provided by SPE 503. In some classes of 

20 SPUs 500, for example, the kernel memory manager 578 may use 

hardware memory management unit (MMU) 540 to provide page 
level protection within the SPU 500. Such a hardware-based 
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memory management system provides an effective mechanism 
for protecting VDE component assemblies 690 from compromise 
by "rogue" load modules. 

5 In addition, memory management provided by memory 

manager 578 operating at least in part based on hardware-based 
MMU 540 may securely implement and enforce a memory 
architecture providing multiple protection domains. In such an 
architecture, memory is divided into a plurality of domains that 

10 are largely isolated from each other and share only specific 

memory areas under the control of the memory manager 578. An 
executing process cannot access memory outside its domain and 
can only communicate with other processes through services 
provided by and mediated by privileged kernel/dispatcher 

15 software 552 within the SPU 500. Such an architecture is more 

secure if it is enforced at least in part by hardware within MMU 
540 that c ann ot be modified by any software-based process 
executing within SPU 500. 

20 In the preferred embodiment, access to services 

implemented in the ROM 532 and to physical resources such as 
NVRAM 534b and RTC 528 are mediated by the combination of 
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privileged kernel/dispatcher software 552 and hardware within 
MMU 540. ROM 532 and RTC 528 requests are privileged in 
order to protect access to critical system component routines (e.g., 
RTC 528). 

5 

Memory manager 578 is responsible for allocating and 
deallocating memory; supervising sharing of memory resources 
between processes; and enforcing memory access/use restriction. 
The SPE kernel/dispatcher memory manager 578 typically 

10 initially allocates all memory to kernel 552, and may be 

configured to permit only process-level access to pages as they 
are loaded by a specific process. In one example SPE operating 
system configuration, memory manager 578 allocates memory 
using a simplified allocation mechanism. A list of each memory 

15 page accessible in SPE 503 may be represented using a bit map 

allocation vector, for example. In a memory block, a group of 
contiguous memory pages may start at a specific page number. 
The size of the block is measured by the number of memory pages 
it spans. Memory allocation may be recorded by setting/clearing 

20 the appropriate bits in the allocation vector. 
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To assist in memory management functions, a "dope 
vector" may be prepended to a memory block. The "dope vector" 
may contain information allowing memory manager 578 to 
manage that memory block. In its simplest form, a memory block 

5 may be structured as a "dope vector" followed by the actual 

memory area of the block. This "dope vector" may include the 
block number, support for dynamic paging of data elements, and 
a marker to detect memory overwrites. Memory manager 578 
may track memory blocks by their block number and convert the 

10 block number to an address before use. All accesses to the 

memory area can be automatically offset by the size of the "dope 
vector" during conversion from a block memory to a physical 
address. "Dope vectors" can also be used by virtual memory 
manager 580 to help manage virtual memory. 

15 

The ROM 532 memory management task performed by 
memory manager 578 is relatively simple in the preferred 
embodiment. All ROM 532 pages may be flagged as "read only" 
and as "non-pagable." EEPROM 532B memory management 
20 may be slightly more complex since the "burn count" for each 

EEPROM page may need to be retained. SPU EEPROM 532B 
may need to be protected from all uncontrolled writes to conserve 
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the limited writable lifetime of certain types of this memory. 
Furthermore, EEPROM pages may in some cases not be the 
same size as memory management address pages. 

SPU NVRAM 534b is preferably battery backed RAM that 
has a few access restrictions. Memory manager 578 can ensure 
control structures that must be located in NVRAM 534b are not 
relocated during "garbage collection" processes. As discussed 
above, memory manager 578 (and MMU 540 if present) may 
protect NVRAM 534b and RAM 534a at a page level to prevent 
tampering by other processes. 

Virtual memory manager 580 provides paging for 
programs and data between SPU external memory and SPU 
internal RAM 534a. It is likely that data structures and 
executable processes will exceed the limits of any SPU 500 
internal memory. For example, PERCs 808 and other 
fundamental control structures may be fairly large, and "bit map 
meters" may be, or become, very large. This eventuality may be 
addressed in two ways: 

(1) subdividing load modules 1100; and 

(2) supporting virtual paging. 
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Load modules 1100 can be "subdivided" in that in many 
instances they can be broken up into separate components only a 
subset of which must be loaded for execution. Load modules 1100 
are the smallest pagable executable element in this example. 
Such load modules 1100 can be broken up into separate 
components (e.g., executable code and plural data description 
blocks), only one of which must be loaded for simple load modules 
to execute. This structure permits a load module 1100 to initially 
load only the executable code and to load the data description 
blocks into the other system pages on a demand basis. Many 
load modules 1100 that have executable sections that are too 
large to fit into SPU 500 can be restructured into two or more 
smaller independent load modules. Large load modules may be 
manually "split" into multiple load modules that are "chained" 
together using explicit load module references. 

Although "demand paging" can be used to relax some of 
these restrictions, the preferred embodiment uses virtual paging 
to manage large data structures and executables. Virtual 
Memory Manager 580 "swaps" information (e.g., executable code 
and/or data structures) into and out of SPU RAM 534a, and 
provides other related virtual memory management services to 
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allow a full virtual memory management capability. Virtual 
memory management may be important to allow limited resource 
SPU 500 configurations to execute large and/or multiple tasks. 

5 C. SPE Load Module Execution Manager 568 

The SPE (HPE) load module execution manager CLMEM") 
568 loads executables into the memory managed by memory 
manager 578 and executes them. LMEM 568 provides 
mechanisms for tracking load modules that are currently loaded 
10 inside the protected execution environment. LMEM 568 also 

provides access to basic load modules and code fragments stored 
within, and thus always available to, SPE 503. LMEM 568 may 
be called, for example, by load modules 1100 that want to execute 
other load modules. 

15 

In the preferred embodiment, the load module execution 
manager 568 includes a load module executor ("program loader") 
570, one or more internal load modules 572, and library routines 
574. Load module executor 570 loads executables into memory 
20 (e.g., after receiving a memory allocation from memory manager 

578) for execution. Internal load module library 572 may provide 
a set of commonly used basic load modules 1100 (stored in ROM 
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532 or NVRAM 534b, for example). Library routines 574 may 
provide a set of commonly used code fragments/routines (e.g., 
bootstrap routines) for execution by SPE 503. 

Library routines 574 may provide a standard set of library 
functions in ROM 532. A standard list of such library functions 
along with their entry points and parameters may be used. Load 
modules 1100 may call these routines (e.g., using an interrupt 
reserved for this purpose). Library calls may reduce the size of 
load modules by moving commonly used code into a central 
location and permitting a higher degree of code reuse. All load 
modules 1100 for use by SPE 503 are preferably referenced by a 
load module execution manager 568 that maintains and scans a 
list of available load modules and selects the appropriate load 
module for execution. If the load module is not present within 
SPE 503, the task is "slept* and LMEM 568 may request that the 
load module 1100 be loaded from secondary storage 562. This 
request may be in the form of an RPC call to secure database 
manager 566 to retrieve the load module and associated data 
structures, and a call to encrypt/decrypt manager 556 to decrypt 
the load module before storing it in memory allocated by memory 
manager 578. 
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In somewhat more detail, the preferred embodiment 
executes a load module 1100 by passing the load module 
execution manager 568 the name (e.g., VDE ID) of the desired 
load module 1100. LMEM 568 first searches the list of "in 
memory" and "built-in" load modules 572. If it cannot find the 
desired load module 1100 in the list, it requests a copy from the 
secure database 610 by issuing an RPC request that may be 
handled by ROS secure database manager 744 shown in Figure 
12. Load module execution manager 568 may then request 
memory manager 578 to allocate a memory page to store the load 
module 1100. The load module execution manager 568 may copy 
the load module into that memory page, and queue the page for 
decryption and security checks by encrypt/decrypt manager 556 
and key and tag manager 558. Once the page is decrypted and 
checked, the load module execution manager 568 checks the 
validation tag and inserts the load module into the list of paged 
in modules and returns the page address to the caller. The caller 
may then call the load module 1100 directly or allow the load 
module execution module 570 to make the call for it. 

Figure 15a shows a detailed example of a possible format 
for a channel header 596 and a channel 594 containing channel 
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detail records 594(1), 594(2), . . . 594(N). Channel header 596 
may include a channel ID field 597(1), a user ID field 597(2), an 
object ID field 597(3), a field containing a reference or other 
identification to a "right" (i.e., a collection of events supported by 
methods referenced in a PERC 808 and/or "user rights table" 464) 
597(4), an event queue 597(5), and one or more fields 598 that 
cross-reference particular event codes with channel detail records 
("CDRs"). Channel header 596 may also include a "jump" or 
reference table 599 that permits addressing of elements within 
an associated component assembly or assemblies 690. Each CDR 
594(1), ♦ . . 594(N) corresponds to a specific event (event code) to 
which channel 594 may respond. In the preferred embodiment, 
these CDRs may include explicitly and/or by reference each 
method core 1000N (or fragment thereof), load module 1100 and 
data structure(s), (e.g., URT, UDE 1200 and/or MDE 1202) 
needed to process the corresponding event. In the preferred 
embodiment, one or more of the CDRs (e.g., 594(1)) may reference 
.a control method and a URT 464 as a data structure. 

Figure 15b shows an example of program control steps 
performed by SPE 503 to "open" a channel 594 in the preferred 
embodiment. In the preferred embodiment, a channel 594 
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provides event processing for a particular VDE object 300, a 
particular authorized user, and a particular "right" (i.e., type of 
event). These three parameters may be passed to SPE 503. Part 
of SPE kernel/dispatcher 552 executing within a "channel 0" 
constructed by low level services 582 during a "bootstrap* routine 
may respond initially to this "open channel" event by allocating 
an available channel supported by the processing resources of 
SPE 503 (block 1125). This "channel 0" "open channel" task may 
then issue a series of requests to secure database manager 566 to 
obtain the "blueprint" for constructing one or more component 
assemblies 690 to be associated with channel 594 (block 1127). 
In the preferred embodiment, this "blueprint" may comprise a 
PERC 808 and/or URT 464. In may be obtained by using the 
"Object, User, Right" parameters passed to the "open channel" 
routine to "chain" together object registration table 460 records, 
user/object table 462 records, URT 464 records, and PERC 808 
records. This "open channel" task may preferably place calls to 
key and tag manager 558 to validate and correlate the tags 
associated with these various records to ensure that they are 
authentic and match. The preferred embodiment process then 
may write appropriate information to channel header 596 (block 
1129). Such information may include, for example, User ID, 



-344- 



Object ID, and a reference to the "right* that the channel will 
process. The preferred embodiment process may next use the 
"blueprint" to access (e.g, the secure database manager 566 
and/or from load module execution manager library(ies) 568) the 
appropriate "control method" that may be used to, in effect, 
supervise execution of all of the other methods 1000 within the 
channel 594 (block 1131). The process may next "bind" this 
control method to the channel (block 1133), which step may 
include binding information from a URT 464 into the channel as 
a data structure for the control method. The process may then 
pass an "initialization" event into channel 594 (block 1135). This 
"initialization" event may be created by the channel services 
manager 562, the process that issued the original call requesting 
a service being fulfilled by the channel being built, or the control 
method just bound to the channel could itself possibly generate 
an initialization event which it would in effect pass to itself. 

In response to this "initialization" event, the control 
method may construct the channel detail records 594(1), . . . 
594(N) used to handle further events other than the 
"initialization" event. The control method executing "within" the 
channel may access the various components it needs to construct 
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associated component assemblies 690 based on the ^blueprint" 
accessed at step 1127 (block 1137). Each of these components is 
bound to the channel 594 (block 1139) by constructing an 
associated channel detail record specifying the method core(s) 
5 1000N, load module(s) 1100, and associated data structure(s) (e.g., 

UDE(s) 1200 and/or MDE(s) 1202) needed to respond to the 
event. The number of channel detail records will depend on the 
number of events that can be serviced by the "right," as specified 
by the "blueprint" (i.e., UKT 464). During this process, the 

10 control method will construct "swap blocks" to, in effect, set up all 

required tasks and obtain necessary memory allocations from 
kernel 562. The control method will, as necessary, issue calls to 
secure database manager 566 to retrieve necessary components 
from secure database 610, issue calls to encrypt/decrypt manager 

15 556 to decrypt retrieved encrypted information, and issue calls to 

key and tag manager 558 to ensure that all retrieved components 
are validated. Each of the various component assemblies 690 so 
constructed are "bound" to the channel through the channel 
header event code/pointer records 598 and by constructing 

20 appropriate swap blocks referenced by channel detail records 

594(1), . . . 594(N). When this process is complete, the channel 
594 has been completely constructed and is ready to respond to 
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further events. As a last step, the Figure 15b process may, if 
desired, deallocate the "initialization" event task in order to free 
up resources. 

5 Once a channel 594 has been constructed in this fashion, it 

will respond to events as they arrive. Channel services manager 
562 is responsible for dispatching events to channel 594. Each 
time a new event arrives (e.g., via an RPC call), channel services 
manager 562 examines the event to determine whether a channel 

10 already exists that is capable of processing it. If a channel does 

exist, then the channel services manager 562 passes the event to 
that channel. To process the event, it may be necessary for task 
manager 576 to "swap in" certain "swappable blocks" defined by 
the channel detail records as active tasks. In this way, 

15 executable component assemblies 690 formed during the channel 

open process shown in Figure 15b are placed into active secure 
execution space, the particular component assembly that is 
activated being selected in response to the received event code. 
The activated task will then perform its desired function in 

20 response to the event. 
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To destroy a ch anne l, the various swap blocks defined by 
the channel detail records are destroyed, the identification 
information in the channel header 596 is wiped clean, and the 
channel is made available for re-allocation by the "channel 0" 
5 n open channel" task. 

D. SPE Interrupt Handlers 584 

As shown in Figure 13, kernel/dispatcher 552 also provides 
internal interrupt handlers) 584. These help to manage the 

10 resources of SPU 500. SPU 500 preferably executes in either 

"interrupt" or "polling" mode for all significant components. In 
polling mode, kernel/dispatcher 552 may poll each of the 
sections/circuits within SPU 500 and emulate an interrupt for 
them. The following interrupts are preferably supported by SPU 

15 500 in the preferred embodiment: 

C "tick" of RTC 528 
C interrupt from bus interface 530 
C power fail interrupt 
C watchdog timer interrupt 

20 C interrupt from encrypt/decrypt engine 522 

C memory interrupt (e.g., from MMU 540). 
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When an interrupt occurs, an interrupt controller within 
microprocessor 520 may cause the microprocessor to begin 
executing an appropriate interrupt handler. An interrupt 
handler is a piece of software/firmware provided by 
5 kernel/dispatcher 552 that allows microprocessor 520 to perform 

particular functions upon the occurrence of an interrupt. The 
interrupts may be "vectored" so that different interrupt sources 
may effectively cause different interrupt handlers to be executed. 

10 A "timer tick" interrupt is generated when the real-time 

ETC 528 "pulses." The timer tick interrupt is processed by a 
timer tick interrupt handler to calculate internal device date/time 
and to generate timer events for channel processing. 

15 The bus interface unit 530 may generate a series of 

interrupts. In the preferred embodiment, bus interface 530, 
modeled after a USART, generates interrupts for various 
conditions (e.g., "receive buffer full," "transmitter buffer empty," 
and "status word change"). Kernel/dispatcher 552 services the 

20 transmitter buffer empty interrupt by sending the next character 

from the transmit queue to the bus interface 530. 
Kernel/dispatcher interrupt handler 584 may service the received 
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buffer full interrupt by reading a character, appending it to the 
current buffer, and processing the buffer based on the state of the 
service engine for the bus interface 530. Kernel/dispatcher 552 
preferably processes a status word change interrupt and 
5 addresses the appropriate send/receive buffers accordingly. 



SPU 500 generates a power fail interrupt when it detects 
an immine nt power fail condition. This may require immediate 
action to prevent loss of information. For example, in the 

10 preferred embodiment, a power fail interrupt moves all recently 

written information (Le., "dirty pages") into non-volatile NVRAM 
534b, marks all swap blocks as "swapped out," and sets the 
appropriate power fail flag to facilitate recovery processing. 
Kernel/dispatcher 552 may then periodically poll the "power fail 

15 bit" in a status word until the data is cleared or the power is 

removed completely. 

SPU 500 in the example includes a conventional watchdog 
timer that generates watchdog timer interrupts on a regular 
20 basis. A watchdog timer interrupt handler performs internal 

device checks to ensure that tampering is not occurring. The 
internal clocks of the watchdog timer and RTC 528 are compared 
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to ensure SPU 500 is not being paused or probed, and other 
internal checks on the operation of SPU 500 are made to detect 
tampering. 

The encryption/decryption engine 522 generates an 
interrupt when a block of data has been processed. The kernel 
interrupt handler 584 adjusts the processing status of the block 
being encrypted or decrypted, and passes the block to the next 
stage of processing. The next block scheduled for the encryption 
service then has its key moved into the encrypt/decrypt engine 
522, and the next cryptographic process started. 

A memory management unit 540 interrupt is generated 
when a task attempts to access memory outside the areas 
assigned to it. A memory management interrupt handler traps 
the request, and takes the necessary action (e.g., by initiating a 
control transfer to memory manager 578 and/or virtual memory 
manager 580). Generally, the task will be failed, a page fault 
exception will be generated, or appropriate virtual memory 
page(s) will be paged in. 
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E. Kernel/Dispatcher Low Level Services 582 

Low level services 582 in the preferred embodiment 
provide "low level" functions. These functions in the preferred 
embodiment may include, for example, power-on initialization, 
5 device POST, and failure recovery routines. Low level services 

582 may also in the preferred embodiment provide (either by 
themselves or in combination with authentication 
manager/service communications manager 564) download 
response-challenge and authentication communication protocols, 
10 and may provide for certain low level management of SPU 500 

memory devices such as EEPROM and FLASH memory (either 
alone or in combination with memory manager 578 and/or virtual 
memory manager 580). 

15 F. Kernel/Dispatcher BIU handler 586 

BIU handler 586 in the preferred embodiment manages 
the bus interface unit 530 (if present). It may, for example, 
maintain read and write buffers for the BIU 530, provide BIU 
startup initialization, etc. 

20 
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G. Kernel/Dispatcher DTD Interpreter 590 

DTD interpreter 590 in the preferred embodiment handles 
data formatting issues. For example, the DTD interpreter 590 
may automatically open data structures such as UDEs 1200 
based on formatting instructions contained within DTDs. 

The SPE kernel/dispatcher 552 discussed above supports 
all of the other services provided by SPE 503. Those other 
services are discussed below. 



II. SPU Channel Services Manager 562 

"Channels" are the basic task processing mechanism of 
SPE 503 (HPE 655) in the preferred embodiment. ROS 602 
provides an event-driven interface for "methods." A "channel" 

15 allows component assemblies 690 to service events. A "channel" 

is a conduit for passing "events" from services supported by SPE 
503 (HPE 655) to the various methods and load modules that 
have been specified to process these events, and also supports the 
assembly of component assemblies 690 and interaction between 

20 component assemblies. In more detail, "channel" 594 is a data 

structure maintained by channel manager 593 that "binds" 
together one or more load modules 1100 and data structures (e.g., 
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UDEs 1200 and/or MDEs 1202) into a component assembly 690. 
Channel services manager 562 causes load module execution 
manager 569 to load the component assembly 690 for execution, 
and may also be responsible for passing events into the channel 
5 594 for response by a component assembly 690. In the preferred 

embodiment, event processing is handled as a message to the 
channel service manager 562. 

Figure 15 is a diagram showing how the preferred 
10 embodiment channel services manager 562 constructs a 

"channel" 594, and also shows the relationship between the 
channel and component assemblies 690. Briefly, the SPE 
channel manager 562 establishes a "channel" 594 and an 
associated "channel header" 596. The channel 594 and its header 
15 596 comprise a data structure that ''binds" or references elements 

of one or more component assemblies 690. Thus, the channel 594 
is the mech anis m in the preferred embodiment that collects 
together or assembles the elements shown in Figure HE into a 
component assembly 690 that may be used for event processing. 

20 

The channel 594 is set up by the channel services manager 
562 in response to the occurrence of an event. Once the channel 
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is created, the channel services manager 562 may issue function 
calls to load module execution manager 568 based on the channel 
594. The load module execution manager 568 loads the load 
modules 1100 referenced by a channel 594, and requests 
execution services by the kernel/dispatcher task manager 576. 
The kernel/dispatcher 552 treats the event processing request as 
a task, and executes it by executing the code within the load 
modules 1100 referenced by the channel. 

The channel services manager 562 may be passed an 
identification of the event (e.g., the "event code"). The channel 
services manager 562 parses one or more method cores 1000' that 
are part of the component assembly(ies) 690 the channel services 
manager is to assemble. It performs this parsing to determine 
which method(s) and data structure(s) are invoked by the type of 
event. Channel manager 562 then issues calls (e.g., to secure 
database manager 566) to obtain the methods and data 
structure(s) needed to build the component assembly 690. These 
called-for method(s) and data structure(s) (e.g., load modules 
1100, UDEs 1200 and/or MDEs 1202) are each decrypted using 
encrypt/decrypt manager 556 (if necessary), and are then each 
validated using key and tag manager 558. Channel manager 562 
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constructs any necessary "jump table" references to, in effect, 
"link" or "bind" the elements into a single cohesive executable so 
the load module(s) can reference data structures and any other 
load module(s) in the component assembly. Channel manager 
5 562 may then issue calls to LMEM 568 to load the executable as 

an active task. 

Figure 15 shows that a channel 594 may reference another 
channel. An arbitrary number of channels 594 may be created by 
10 channel manager 594 to interact with one another. 

"Channel header" 596 in the preferred embodiment is (or 
references) the data structure(s) and associated control 
program(s) that queues events from channel event sources, 

15 processes these events, and releases the appropriate tasks 

specified in the "channel detail record" for processing. A "channel 
detail record" in the preferred embodiment links an event to a 
"swap block" (ie., task) associated with that event. The "swap 
block" may reference one or more load modules 1100, UDEs 1200 

20 and private data areas required to properly process the event. 

One swap block and a corresponding channel detail item is 
created for each different event the channel can respond to. 
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In the preferred embodiment, Channel Services Manager 
562 may support the following (internal) calls to support the 
creation and maintenance of channels 562: 



5 


Call Name 


Source 


Description 




TV IXvC 

Event" 


Write 


Writes an event to the channel for response by 
thA channel. The Write Event call thus permit 
the caller to insert an event into the event 
queue associated with the channel. The event 
will be processed in turn by the channel 594. 




"Bind 
Item" 


Ioctl 


Binds an item to a channel with the 
appropriate processing algorithm. The Bind 
Item call permits the caller to bind a VDE item 
ID to a channel (e.g., to create one or more swap 
blocks associated with a channel). This call 
may manipulate the contents of individual 
swap blocks. 


10 


"Unbind 
Item" 


Ioctl 


Unbinds an item from a channel with the 
appropriate processing algorithm. The Unbind 
Item call permits the caller to break the binding 
of an item to a swap block. This call may 
manipulate the contents of individual swap 
blocks. 
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SPE RPC Manager 550 

As described in connection with Figure 12, the architecture 
of ROS 602 is based on remote procedure calls in the preferred 
embodiment. ROS 602 includes an RPC Manager 732 that 
5 passes RPC calls between services each of which present an RPC 

service interface ("RSI") to the RPC manager. In the preferred 
embodiment, SPE 503 (HPE 655) is also built around the same 
RPC concept. The SPE 503 (HPE 655) may include a number of 
internal modular service providers each presenting an RSI to an 
10 RPC manager 550 internal to the SPE (HPE). These internal 

service providers may communicate with each other and/or with 
ROS RPC manager 732 (and thus, with any other service 
provided by ROS 602 and with external services), using RPC 
service requests. 

15 

RPC manager 550 within SPE 503 (HPE 655) is not the 
same as RPC manager 732 shown in Figure 12, but it performs a 
similar function within the SPE (HPE): it receives RPC requests 
and passes them to the RSI presented by the service that is to 
20 fulfill the request. In the preferred embodiment, requests are 

passed between ROS RPC manager 732 and the outside world 
(i.e., SPE device driver 736) via the SPE (HPE) 
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Kernel/Dispatcher 552. Kernel/Dispatcher 552 may be able to 
service certain RPC requests itself, but in general it passes 
received requests to RPC manager 550 for routing to the 
appropriate service internal to the SPE (HPE). In an alternate 
embodiment, requests may be passed directly between the HPE, 
SPE, API, Notification interface, and other external services 
instead of routing them through the ROS RPC manager 732. The 
decision on which embodiment to use is part of the scalability of 
the system; some embodiments are more efficient than others 
tinder various traffic loads and system configurations. Responses 
by the services (and additional service requests they may 
themselves generate) are provided to RPC Manager 550 for 
routing to other service(s) internal or external to SPE 503 (HPE 
655). 

SPE RPC Manager 550 and its integrated service manager 
uses two tables to dispatch remote procedure calls: an RPC 
services table, and an optional RPC dispatch table. The RPC 
services table describes where requests for specific services are to 
be routed for processing. In the preferred embodiment, this table 
is constructed in SPU RAM 534a or NVRAM 534b, and lists each 
RPC service "registered" within SPU 500. Each row of the RPC 
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services table contains a service ID, its location and address, and 
a control byte. In simple implementations, the control byte 
indicates only that the service is provided internally or 
externally. In more complex implementations, the control byte 
5 can indicate an instance of the service (e.g., each service may 

have multiple "instances" in a multi-tasking environment). ROS 
RPC manager 732 and SPE 503 may have symmetric copies of 
the RPC services table in the preferred embodiment. If an RPC 
service is not found in the RPC services table, SPE 503 may 
10 either reject it or pass it to ROS RPC manager 732 for service. 

The SPE RPC manager 550 accepts the request from the 
RPC service table and processes that request in accordance with 
the internal priorities associated with the specific service. In 

15 SPE 503, the RPC service table is extended by an RPC dispatch 

table. The preferred embodiment RPC dispatch table is 
organized as a list of Load Module references for each RPC 
service supported internally by SPE 503. Each row in the table 
contains a load module ID that services the call, a control byte 

20 that indicates whether the call can be made from an external 

caller, and whether the load module needed to service the call is 
permanently resident in SPU 500. The RPC dispatch table may 
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be constructed in SPU ROM 532 (or EEPROM) when SPU 
firmware 508 is loaded into the SPU 500. If the RPC dispatch 
table is in EEPROM, it flexibly allows for updates to the services 
without load module location and version control issues. 

5 

In the preferred embodiment, SPE RPC manager 550 first 
references a service request against the RPC service table to 
determine the location of the service manager that may service 
the request. The RPC manager 550 then routes the service 

10 request to the appropriate service manager for action. Service 

requests are handled by the service manager within the SPE 503 
using the RPC dispatch table to dispatch the request. Once the 
RPC manager 550 locates the service reference in the RPC 
dispatch table, the load module that services the request is called 

15 and loaded using the load module execution manager 568. The 

load module execution manager 568 passes control to the 
requested load module after performing all required context 
configuration, or if necessary may first issue a request to load it 
from the external management files 610. 

20 
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SPU Time Base Manager 554 

The time base manager 554 supports calk that relate to 
the real time clock ("RTC") 528. In the preferred embodiment, 
the time base manager 554 is always loaded and ready to respond 
5 to time based requests. 



The table below lists examples of basic calls that may be 
supported by the time base manager 554: 



Call Name 


Description 


Independent requests 


Get Time 


Returns the time (local, GMT, or ticks). 


Set time 


Sets the time in the RTC 528. Access to this 
command may be restricted to a VDE 
administrator. 


Adjust time 


Changes the time in the RTC 528. Access to 
this command may be restricted to a VDE 
administrator. 


Set Time 
Parameter 


Set GMT / local time conversion and the 
current and allowable magnitude of user 
adjustments to RTC 528 time. 


Channel Services Manager Requests 


Bind Time 


Bind timer services to a channel as an event 
source. 


Unbind 
Time 


Unbind timer services from a channel as an 
event source. 
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1 Call Name 


Description 


Set Alarm 


Sets an alarm notification for a specific time. 
The user will be notified by an alarm event at 
the time of the alarm. Parameters to this 
request determine the event, frequency, and 
requested processing for the alarm. 


1 Clear Alarm 


Cancels a requested alarm notification. 



SPU Encryption/Decryption Manager 556 

The Encryption/Decryption Manager 556 supports calls to 
the various encryption/decryption techniques supported by SPE 
503/HPE 655. It may be supported by a hardware-based 
enciyption/decryption engine 522 within SPU 500. Those 
encryption/decryption technologies not supported by SPU 
encrypt/decrypt engine 522 may be provided by encrypt/decrypt 
manager 556 in software. The primary bulk 
encryption/decryption load modules preferably are loaded at all 
times, and the load modules necessary for other algorithms are 
preferably paged in as needed. Thus, if the primary bulk 
encryption/decryption algorithm is DES, only the DES load 
modules need be permanently resident in the RAM 534a of SPE 
503/HPE 655. 
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The following are examples of RPC calls supported by 
Encrypt/Decrypt Manager 556 in the preferred embodiment: 



Call Name 


Description 


PK Encrypt 


Encrypt a block using a PK (public key) 
algorithm. 


PK Decrypt 


Decrypt a block using a PK algorithm. 


DES 

Encrypt 


Encrypt a block using DES. 


DES 
Decrypt 


Decrypt a block using DES. 


RC-4 
Encrypt 


Encrypt a block using the RC-4 (or other bulk 
encryption) algorithm. 


TJpJ 

rvU-4 
Decrypt 


"nprrvnt a block using the RC-4 (or other bulk 
encryption) algorithm. 


Initialize 

DES 

Instance 


Initialize DES instance to be used. 


Initialize 

RC-4 

Instance 


Initialize RC-4 instance to be used. 


Initialize 

MD5 

Instance 


Initialize MD5 instance to be used. 


Process MD5 
Block 


Process MD5 block. J 
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The call parameters passed may include the key to be used; 
mode (encryption or decryption); any needed Initialization 
Vectors; the desired cryptographic operating (e.g., type of 
feedback); the identification of the cryptographic instance to be 
5 used; and the start address, destination address, and length of 

the block to be encrypted or decrypted. 

SPU Key and Tag Manager 658 

The SPU Key and Tag Manager 558 supports calls for key 
10 storage, key and management file tag look up, key convolution, 

and the generation of random keys, tags, and transaction 
numbers. 

The foDowing table shows an example of a list of SPE/HPE 
15 key and tag manager service 558 calls: 



Call Name 


Description 




Kev Requests 




Get Key 


Retrieve the requested key. 




Set Kev - 


Set (store) the specified key. 




Generate Key 


Generate a key (pair) for a specified algorithm 




Generate Convoluted 
Kev 


Generate a key using a specified convolution s 
and algorithm parameter block. 


gorith 


Get Convolution 
Algorithm 


Return the currently set (default) convolution 
parameters for a specific convolution alerorithi 


L. 
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Set Convolution 
Algorithm 


Sets the convolution parameters for a specific 
convolution algorithm (calling routine must pi 
tag to read returned contents). 


Dvide 


Taff Requests 






Get the validation (or other) tag for a specific ^ 
ID. 


DE It 


Set Tag 


Set the validation (or other) tag for a specific ^ 
ID to a known value. 


DE It 


Calculate Hash Bloc! 
Number 


Calculate the "hash block number" for a specil 
Item ID. 


cVDE 


Set Hash Parameters 


Set the hash parameters and hash algorithm, 
resynchronization of the hash table. 


Force 


Get Hash Parameter! 


; Retrieve the current hash parameters/alfforitl: 


m. 


Synchronize 
Management Files 


Synchronize the management files and rebuilc 
block tables based on information found in the 
Reserved for VDE administrator. 


theh 
tables 



Keys and tags may be securely generated within SPE 503 
(HPE 655) in the preferred embodiment. The key generation 
algorithm is typically specific to each type of encryption 
supported. The generated keys may be checked for cryptographic 
weakness before they are used. A request for Key and Tag 
Manager 558 to generate a key, tag and/or transaction number 
preferably takes a length as its input parameter. It generates a 
random number (or other appropriate key value) of the requested 
length as its output. 

The key and tag manager 558 may support calls to retrieve 
specific keys from the key storage areas in SPU 500 and any keys 
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stored external to the SPU. The basic format of the calls is to 
request keys by key type and key number. Many of the keys are 
periodically updated through contact with the VDE 
administrator, and are kept within SPU 500 in NVRAM 534b or 
EEPROM because these memories are secure, updatable and 
non-volatile. 

SPE 503/HPE 655 may support both Public Key type keys 
and Bulk Encryption type keys. The public key (PK) encryption 
type keys stored by SPU 500 and managed by key and tag 
manager 558 may include, for example, a device public key, a 
device private key, a PK certificate, and a public key for the 
certificate. Generally, public keys and certificates can be stored 
externally in non-secured memory if desired, but the device 
private key and the public key for the certificate should only be 
stored internally in an SPU 500 EEPROM or NVRAM 534b. 
Some of the types of bulk encryption keys used by the SPU 500 
may include, for example, general-purpose bulk encryption keys, 
administrative object private header keys, stationary object 
private header keys, traveling object private header keys, 
download/initiahzation keys, backup keys, trail keys, and 
management file keys. 
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As discussed above, preferred embodiment Key and Tag 
Manager 558 supports requests to adjust or convolute keys to 
make new keys that are produced in a deterministic way 
dependent on site and/or time, for example. Key convolution is 
5 an algorithmic process that acts on a key and some set of input 

parameters) to yield a new key. It can be used, for example, to 
increase the number of keys available for use without incurring 
additional key storage space. It may also be used, for example, as 
a process to "age" keys by incorporating the value of real-time 
10 RTC 528 as parameters. It can be used to make keys site specific 

by incorporating aspects of the site ID as parameters. 

Key and Tag Manager 558 also provides services relating 
to tag generation and management. In the preferred 

15 embodiment, transaction and access tags are preferably stored by 

SPE 503 (HPE 655) in protected memory (e.g., within the 
NVRAM 534b of SPU 500). These tags may be generated by key 
and tag manager 558. They are used to, for example, check 
access rights to, validate and correlate data elements. For 

20 example, they may be used to ensure components of the secured 

data structures are not tampered with outside of the SPU 500. 
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Key and tag manager 558 may also support a trail transaction 
tag and a communications transaction tag. 



10 



15 



20 



SPU Summary Services Manager 560 

SPE 503 maintains an audit trail in reprogrammable non- 
volatile memory within the SPU 500 and/or in secure database 
610. This audit trail may consist of an audit summary of budget 
activity for financial purposes, and a security summary of SPU 
use. When a request is made to the SPU, it logs the request as 
having occurred and then notes whether the request succeeded or 
failed. All successful requests may be summed and stored by 
type in the SPU 500. Failure information, including the elements 
listed below, may be saved along with details of the failure: 



Control Information Retained in an 
SPE on Access Failures 



Object ID 



User ID 



Type of failure 



Time of failure 



25 



This information may be analyzed to detect cracking attempts or 
to determine patterns of usage outside expected (and budgeted) 
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norms. The audit trail histories in the SPU 500 may be retained 
until the audit is reported to the appropriate parties. This will 
allow both legitimate failure analysis and attempts to 
cryptoanalyze the SPU to be noted. 

5 

Summary services manager 560 may store and maintain 
this internal summary audit information. This audit information 
can be used to check for security breaches or other aspects of the 
operation of SPE 503. The event summaries may be maintained, 
10 analyzed and used by SPE 503 (HPE 655) or a VDE 

administrator to deter min e and potentially limit abuse of 
electronic appliance 600. In the preferred embodiment, such 
parameters may be stored in secure memory (e.g., within the 
NVRAM 534b of SPU 500). 

15 

There are two basic structures for which summary services 
are used in the preferred embodiment. One (the "event summary 
data structure") is VDE administrator specific and keeps track of 
events. The event summary structure may be maintained and _ 
20 audited during periodic contact with VDE administrators. The 

other is used by VDE administrators and/or distributors for 
overall budget. A VDE administrator may register for event 
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summaries and an overall budget summary at the time an 
electronic appliance 600 is initialized. The overall budget 
summary may be reported to and used by a VDE administrator 
in determining distribution of consumed budget (for example) in 
5 the case of corruption of secure management files 610. 

Participants that receive appropriate permissions can register 
their processes (e.g., specific budgets) with summary services 
manager 560, which may then reserve protected memory space 
(e.g., within NVRAM 534b) and keep desired use and/or access 
10 parameters. Access to and modification of each summary can be 

controlled by its own access tag. 

The following table shows an example of a list of PPE 
summary service manager 560 service calls: 

15 



Call Name 


Description 


Create summary 
info 


Create a summary service if the user 
has a "ticket" that permits her to 
request this service. 


Get value 


Return the current value of the 
summary service. The caller must 
present an appropriate tag (and/or jj 
"ticket") to use this request. j] 


Set value 


Set the value of a summarv service. II 
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Increment 


Increment the specified summary 
service(e.g., a scalar meter summary 
data area). The caller must present 
an appropriate tag (and/or "ticket") to 
use this request. 


Destroy 


Destroy the specified summary service 
if the user has a tag and/or "ticket" 
that permits them to request this 
service. 



5 In the preferred embodiment, the event summary data 

structure uses a fixed event number to index into a look up table. 
The look up table contains a value that can be configured as a 
counter or a counter plus limit. Counter mode may be used by 
VDE administrators to determine device usage. The limit mode 

10 may be used to limit tampering and attempts to misuse the 

electronic appliance 600. Exceeding a limit will result in SPE 
503 (HPE 655) refusing to service user requests until it is reset 
by a VDE administrator. Calls to the system wide event 
summary process may preferably be built into all load modules 

15 that process the events that are of interest. 

The following table shows examples of events that may be 
separately metered by the preferred embodiment event summary 
data structure: 
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Event Type 


1 


Successful 


Initialization completed successfully. 


Events 


T Toot Qiri-ViP'nfipa'Kfyn flprPDted 


Conimiinications established. 


Channel loads set for specified values. 


Decryption completed. | 


Key information updated. 


New budget created or existing budget j 
updated. 


New billing information generated or 
existing billing updated. 


New meter set up or existing meter 
updated. 


New PERC created or existing PERC I 
updated. 1 


New obiects registered. 


Administrative objects successtully 
Tvroppssed 


Audit processed successfully. 


All other events. 


r ailed vents 


TnvH oliTpfinTi fflilpfl 
l 1.1 i iia aLiuii icuivu« 


Authentication failed. 


Communication attempt failed. 


Request to load a channel failed. 


Validation attempt unsuccessful. 


Link to subsidiary item failed correlation 
tag match. 
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Authorization attempt failed. 




Decryption attempt failed. j 




Available budget insufficient to complete 
requested procedure. 




Audit did not occur. 




Administrative object did not process 
correctly. 




Other failed events. 



Another, "overall currency budget" summary data 
structure maintained by the preferred embodiment summary 
5 services manager 560 allows registration of VDE electronic 

appliance 600. The first entry is used for an overall currency 
budget consumed value, and is registered by the VDE 
administrator that first initializes SPE 503 (HPE 655). Certain 
currency cons uming load modules and audit load modules that 
10 complete the auditing process for consumed currency budget may 

call the summary services manager 560 to update the currency 
consumed value. Special authorized load modules may have 
access to the overall currency summary, while additional 
summaries can be registered for by individual providers. 

15 
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SFE Authentication Manager/Service Communications 
Manager 564 

The Authentication Manager/Service Communications 
5 Manager 564 supports calls for user password validation and 

"ticket" generation and validation. It may also support secure 
communications between SPE 503 and an external node or device 
(e.g., a VDE administrator or distributor). It may support the 
following examples of authentication-related service requests in 
10 the preferred embodiment: 



Call Name 


Description 


User Services 


Create User 


Creates a new user and stores Name Services 
Records (NSRs) for use by the Name Services 
Manager 752. 


Authenticate 
User 


Authenticates a user for use of the system. This 
request lets the caller authenticate as a specific 
user ID. Group membership is also authenticated 
by this request. The authentication returns a 
"ticket" for the user. 


Delete User 


Deletes a user's NSR and related records. 


Ticket Services 


Generate Ticket 


Generates a "ticket" for use of one or more 
services. 


Authenticate 
Ticket 


Authenticates a "ticket." 
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Not included in the table above are calls to the secure 
communications service. The secure communications service 
5 provided by manager 564 may provide (e.g., in conjunction with 

low-level services manager 582 if desired) secure communications 
based on a public key (or others) challenge-response protocol. 
This protocol is discussed in further detail elsewhere in this 
document. Tickets identify users with respect to the electronic 
10 appliance 600 in the case where the appliance may be used by 

multiple users. Tickets may be requested by and returned to 
VDE software applications through a ticket-granting protocol 
(e.g., Kerberos). VDE components may require tickets to be 
presented in order to authorize particular services. 

15 

SPE Secure Database Manager 566 

Secure database manager 566 retrieves, maintains and 
stores secure database records within secure database 610 on 
memory external to SPE 503. Many of these secure database 
20 files 610 are in encrypted form. All secure information retrieved 

by secure database manager 566 therefore must be decrypted by 
encrypt/decrypt manager 556 before use. Secure information 
(e.g., records of use) produced by SPE 503 (HPE 655) which must 
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be stored external to the secure execution environment are also 
encrypted by encrypt/decrypt manager 556 before they are stored 
via secure database manager 566 in a secure database file 610. 

5 For each VDE item loaded into SPE 503, Secure Database 

manager 566 in the preferred embodiment may search a master 
list for the VDE item ID, and then check the corresponding 
transaction tag ag ains t the one in the item to ensure that the 
item provided is the current item. Secure Database Manager 566 

10 may maintain list of VDE item ID and transaction tags in a "hash 

structure" that can be paged into SPE 503 to quickly locate the 
appropriate VDE item ID. In smaller systems, a look up table 
approach may be used. In either case, the list should be 
structured as a pagable structure that allows VDE item ID to be 

15 located quickly. 

The "hash based" approach may be used to sort the list into 
"hash buckets" that may then be accessed to provide more rapid 
and efficient location of items in the list. In the "hash based" 
20 approach, the VDE item IDs are "hashed" through a subset of the 

full item ID and organized as pages of the "hashed" table. Each 
"hashed" page may contain the rest of the VDE item ID and 
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current transaction tag for each item associated with that page. 
The "hash" table page number may be derived from the 
components of the VDE item ID, such as distribution ID, item ID, 
site ID, user ID, transaction tag, creator ID, type and/or version 
5 The hashing algorithm (both the algorithm itself and the 

parameters to be hashed) may be configurable by a VDE 
administrator on a site by site basis to provide optimum hash 
page use. An example of a hash page structure appears below: 

10 



15 



20 



25 



Field 

Hash Page Header 



Distributor ID 



Item ID 



Site ID 



User ID 



Transaction Tag 



Hash Page Entry 



Creator ID 



Item ID 



Type 



Version 



Transaction Tag 
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In this example, each hash page may contain all of the 
VDE item IDs and transaction tags for items that have identical 
distributor ID, item ID, and user ID fields (site ID will be fixed for 
a given electronic appliance 600). These four pieces of 
5 information may thus be used as hash algorithm parameters. 

The "hash" pages may themselves be frequently updated, 
and should carry transaction tags that are checked each time a 
"hash" page is loaded. The transaction tag may also be updated 
10 each time a "hash" page is written out. 

As an alternative to the hash-based approach, if the 
number of updatable items is kept small (such as in a dedicated 
consumer electronic appliance 600), then assigning each 

15 updatable item a unique sequential site record number as part of 

its VDE item ID may allow a look up table approach to be used. 
Only a small number of bytes of transaction tag are needed per 
item, and a table transaction tag for all frequently updatable 
items can be kept in protected memory such as SPU NVRAM 

20 534b. 
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Random Value Generator Manager 565 

Random Value Generator Manager 565 may generate 
random values. If a hardware-based SPU random value 
generator 542 is present, the Random Value Generator Manager 
5 565 may use it to assist in generating random values. 

Other SPE RPC Services 692 

Other authorized RPC services may be included in SPU 
500 by having them "register" themselves in the RPC Services 

10 Table and adding their entries to the RPC Dispatch Table. For 

example, one or more component assemblies 690 may be used to 
provide additional services as an integral part of SPE 503 and its 
associated operating system. Requests to services not registered 
in these tables will be passed out of SPE 503 (HPE 655) for 

15 external servicing. 

SPE 503 Performance Considerations 

Performance of SPE 503 (HPE 655) is a function of: 
C complexity of the component assemblies used 
20 C number of simultaneous component assembly operations 

C amount of internal SPU memory available 
C speed of algorithm for block encryption/decryption 
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The complexity of component assembly processes along 
with the number of simultaneous component assembly processes 
is perhaps the primary factor in determining performance. These 
factors combine to deter min e the amount of code and data and 
must be resident in SPU 500 at any one time (the minimum 
device size) and thus the number of device size "chunks" the 
processes must be broken down into. Segmentation inherently 
increases run time size over simpler models. Of course, feature 
limited versions of SPU 500 may be implemented using 
significantly smaller amounts of RAM 534. "Aggregate" load 
modules as described above may remove flexibility in configuring 
VDE structures and also further limit the ability of participants 
to individually update otherwise separated elements, but may 
result in a smaller minimum device size. A very simple metering 
version of SPU 500 can be constructed to operate with minimal 
device resources. 

The amount of RAM 534 internal to SPU 500 has more 
impact on the performance of the SPE 503 than perhaps any 
other aspect of the SPU. The flexible nature of VDE processes 
allows use of a large number of load modules, methods and user 
data elements. It is impractical to store more than a small 
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number of these items in ROM 532 within SPU 500. Most of the 
code and data structures needed to support a specific VDE 
process will need to be dynamically loaded into the SPU 500 for 
the specific VDE process when the process is invoked. The 
5 operating system within SPU 500 then may page in the 

necessary VDE items to perform the process. The amount of 
RAM 534 within SPU 500 will directly determine how large any 
single VDE load module plus its required data can be, as well as 
the number of page swaps that will be necessary to run a VDE 

10 process. The SPU I/O speed, encryption/decryption speed, and 

the amount of internal memory 532, 534 will directly affect the 
number of page swaps required in the device. Insecure external 
memory may reduce the wait time for swapped pages to be loaded 
into SPU 500, but will still incur substantial 

15 encryption/decryption penalty for each page. 

In order to maintain security, SPE 503 must encrypt and 
cryptographically seal each block being swapped out to a storage 
device external to a supporting SPU 500, and must similarly 
20 decrypt, verify the cryptographic seal for, and validate each block 

as it is swapped into SPU 500. Thus, the data movement and 



-382- 



WO 96/27155 



PCT/CS96/02303 



encryption/decryption overhead for each swap block has a very 
large impact on SPE performance. 

The performance of an SPU microprocessor 520 may not 
5 significantly impact the performance of the SPE 503 it supports if 

the processor is not responsible for moving data through the 
encrypt/decrypt engine 522. 

VDE Secure Database 610 

10 VDE 100 stores separately deliverable VDE elements in a 

secure (e.g., encrypted) database 610 distributed to each VDE 
electronic appliance 610. The database 610 in the preferred 
embodiment may store and/or manage three basic classes of VDE 
items: 

15 VDE objects, 

VDE process elements, and 
VDE data structures. 

The following table lists examples of some of the VDE 
20 items stored in or managed by information stored in secure 

database 610: 
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Class 


Brief Description 


Objects 


Content Objects 


Provide a container for content. 


Administrative 
Objects 


Provide a container for information 
used to keep VDE 100 operating. 


Traveling Objects 


Provide a container for content and 
control information. 


Smart Objects 


Provide a container for (user- 
specified) processes and data. 


Process 
Elements 


Method Cores 


Provide a mechanism to relate events 
to control mechanisms and 
permissions. 


Load Modules 
TLMs") 


Secure (tamper-resistant) executable 
code. 


Method Data 

Elements 

CMDEs") 


Independently deliverable data 
structures used to control/customize 
methods. 


Data 

Structures 


Permissions 
Records (TERCs*) 


Permissions to use objects; 
blueprints to build component 
assemblies. 


User Data 
Elements CUDEs") 


Basic data structure for storing 
information used in conjunction with 
load modules. 


Administrative 
Data Structures 


Used by VDE node to maintain 
administrative information. 
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Each electronic appliance 600 may have an instance of a 
secure database 610 that securely maintains the VDE items. 
Figure 16 shows one example of a secure database 610. The 
secure database 610 shown in this example includes the following 
5 VDE-protected items: 

C one or more PERCs 808; 

C methods 1000 (including static and dynamic method 

"cores" 1000, and MDEs 1202); 
C Static UDEs 1200a and Dynamic UDEs 1200b; and 
10 C load modules 1100. 

Secure database 610 may also include the following 
additional data structures used and maintained for 
administrative purposes: 
15 C an "object registry" 450 that references an object 

storage 728 containing one or more VDE objects; 
C name service records 452; and 
C configuration records 454 (including site 

configuration records 456 and user configuration 
20 records 458). 
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Secure database 610 in the preferred embodiment does not 
include VDE objects 300, but rather references VDE objects 
stored, for example, on file system 687 and/or in a separate object 
repository 728. Nevertheless, an appropriate "starting point" for 
5 understanding VDE-protected information may be a discussion of 

VDE objects 300. 

VDE Objects 300 

VDE 100 provides a media independent container model 
10 for encapsulating content. Figure 17 shows an example of a 

"logical" structure or format 800 for an object 300 provided by the 
preferred embodiment. 

The generalized "logical object" structure 800 shown in 
15 Figure 17 used by the preferred embodiment supports digital 

content delivery over any currently used media. "Logical object" 
in the preferred embodiment may refer collectively to: content; 
computer software and/or methods used to manipulate, record, 
and/or otherwise control use of said content; and permissions, 
20 limitations, administrative control information and/or 

requirements applicable to said content, and/or said computer 
software and/or methods. Logical objects may or may not be 
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stored, and may or may not be present in, or accessible to, any 
given electronic appliance 600. The content portion of a logical 
object may be organized as information contained in, not 
contained in, or partially contained in one or more objects. 

Briefly, the Figure 17 logical object" structure 800 in the 
preferred embodiment includes a public header 802, private 
header 804, a "private body" 806 containing one or more methods 
1000, permissions record(s) (PERC) 808 (which may include one 
or more key blocks 810), and one or more data blocks or areas 
812. These elements may be "packaged" within a "container" 
302. This generalized, logical object structure 800 is used in the 
preferred embodiment for different types of VDE objects 300 
categorized by the type and location of their content. 

The "container" concept is a convenient metaphor used to 
give a name to the collection of elements required to make use of 
content or to perform an administrative-type activity. Container 
302 typically includes identifying information, control structures 
and content (e.g., a property or administrative data). The term 
"container" is often (e.g., Bento/OpenDoc and OLE) used to 
describe a collection of information stored on a computer system's 
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secondary storage system(s) or accessible to a computer system 
over a co mmuni cations network on a "server's" secondary storage 
system. The "container" 302 provided by the preferred 
embodiment is not so limited or restricted. In VDE 100, there is 
no requirement that this information is stored together, received 
at the same time, updated at the same time, used for only a 
single object, or be owned by the same entity. Rather, in VDE 
100 the container concept is extended and generalized to include 
real-time content and/or online interactive content passed to an 
electronic appliance over a cable, by broadcast, or communicated 
by other electronic communication means. 

Thus, the "complete" VDE container 302 or logical object 
structure 800 may not exist at the user's location (or any other 
location, for that matter) at any one time. The "logical object" 
may exist over a particular period of time (or periods of time), 
rather than all at once. This concept includes the notion of a 
"virtual container" where important container elements may 
exist either as a plurality of locations and/or over a sequence of 
time periods (which may or may not overlap). Of course, VDE 
100 containers can also be stored with all required control 
structures and content together. This represents a continuum: 
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from all content and control structures present in a single 
container, to no locally accessible content or container specific 
control structures. 

5 Although at least some of the data representing the object 

is typically encrypted and thus its structure is not discernible, 
within a PPE 650 the object may be viewed logically as a 
"container" 302 because its structure and components are 
automatically and transparently decrypted. 

10 

A container model merges well with the event-driven 
processes and ROS 602 provided by the preferred embodiment. 
Under this model, content is easily subdivided into small, easily 
manageable pieces, but is stored so that it maintains the 
15 structural richness inherent in unencrypted content. An object 

oriented container model (such as Bento/OpenDoc or OLE) also 
provides many of the necessary "hooks" for inserting the 
necessary operating system integration components, and for 
defining the various content specific methods. 

20 

In more detail, the logical object structure 800 provided by 
the preferred embodiment includes a public (or unencrypted) 



.389- 



header 802 that identifies the object and may also identify one or 
more owners of rights in the object and/or one or more 
distributors of the object. Private (or encrypted) header 804 may 
include a part or all of the information in the public header and 
further, in the preferred embodiment, will include additional data 
for validating and identifying the object 300 when a user 
attempts to register as a user of the object with a service 
clearinghouse, VDE administrator, or an SPU 500. 
Alternatively, information identifying one or more rights owners 
and/or distributors of the object may be located in encrypted form 
within encrypted header 804, along with any of said additional 
validating and identifying data. 

Each logical object structure 800 may also include a 
"private body" 806 cont aining or referencing a set of methods 
1000 (i.e., programs or procedures) that control use and 
distribution of the object 300. The ability to optionally 
incorporate different methods 1000 with each object is important 
to making VDE 100 highly configurable. Methods 1000 perform 
the basic function of defining what users (including, where 
appropriate, distributors, client administrators, etc.), can and 
cannot do with an object 300. Thus, one object 300 may come 
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with relatively simple methods, such as allowing unlimited 
viewing within a fixed period of time for a fixed fee (such as the 
newsstand price of a newspaper for viewing the newspaper for a 
period of one week after the paper's publication), while other 
objects may be controlled by much more complicated (e.g., billing 
and usage limitation) methods. 

Logical object structure 800 shown in Figure 17 may also 
include one or more PERCs 808. PERCs 808 govern the use of an 
object 300, specifying methods or combinations of methods that 
must be used to access or otherwise use the object or its contents. 
The permission records 808 for an object may include key block(s) 
810, which may store decryption keys for accessing the content of 
the encrypted content stored within the object 300. 

The content portion of the object is typically divided into 
portions called data blocks 812. Data blocks 812 may contain any 
sort of electronic information, such as, "content," including 
computer programs, images, sound, VDE administrative 
information, etc. The size and number of data blocks 812 may be 
selected by the creator of the property. Data blocks 812 need not 
all be the same size (size may be influenced by content usage, 
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database format, operating system, security and/or other 
considerations). Security will be enhanced by using at least one 
key block 810 for each data block 812 in the object, although this 
is not required. Key blocks 810 may also span portions of a 
plurality of data blocks 812 in a consistent or pseudo-random 
manner. The spanning may provide additional security by 
applying one or more keys to fragmented or seemingly random 
pieces of content contained in an object 300, database, or other 
information entity. 

Many objects 300 that are distributed by physical media 
and/or by "out of ch anne l" means (e.g., redistributed after receipt 
by a customer to another customer) might not include key blocks 
810 in the same object 300 that is used to transport the content 
protected by the key blocks. This is because VDE objects may 
contain data that can be electronically copied outside the confines 
of a VDE node. If the content is encrypted, the copies will also be 
encrypted and the copier cannot gain access to the content unless 
she has the appropriate decryption key(s). For objects in which 
maintaining security is particularly important, the permission 
records 808 and key blocks 810 will frequently be distributed 
electronically, using secure communications techniques 
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(discussed below) that are controlled by the VDE nodes of the 
sender and receiver. As a result, permission records 808 and key 
blocks 810 will frequently, in the preferred embodiment, be 
stored only on electronic appliances 600 of registered users (and 
5 may themselves be delivered to the user as part of a 

registration/initialization process). In this instance, permission 
records 808 and key blocks 810 for each property can be 
encrypted with a private DES key that is stored only in the 
secure memory of an SPU 500, making the key blocks unusable 
10 on any other user's VDE node. Alternately, the key blocks 810 

can be encrypted with the end user's public key, making those 
key blocks usable only to the SPU 500 that stores the 
corresponding private key (or other, acceptably secure, 
encryption/security techniques can be employed). 

15 

In the preferred embodiment, the one or more keys used to 
encrypt each permission record 808 or other management 
information record will be changed every time the record is 
updated (or after a certain one or more events). In this event, the 
20 updated record is re-encrypted with new one or more keys. 

Alternately, one or more of the keys used to encrypt and decrypt 
management information may be "time aged" keys that 
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automatically become invalid after a period of time. 
Combinations of time aged and other event triggered keys may 
also be desirable; for example keys may change after a certain 
number of accesses, and/or after a certain duration of time or 

5 absolute point in time. The techniques may also be used together 

for any given key or combination of keys. The preferred 
embodiment procedure for constructing time aged keys is a 
one-way convolution algorithm with input parameters including 
user and site information as well as a specified portion of the real 

10 time value provided by the SPU RTC 528. Other techniques for 

time aging may also be used, including for example techniques 
that use only user or site information, absolute points in time, 
and/or duration of time related to a subset of activities related to 
using or decrypting VDE secured content or the use of the VDE 

15 system. 

VDE 100 supports many different types of "objects" 300 
having the logical object structure 800 shown in Figure 17. 
Objects may be classified in one sense based on whether the 
20 protection information is bound together with the protected 

information. For example, a container that is bound by its 
controKs) to a specific VDE node is called a "stationary object" 
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(see Figure 18). A container that is not bound by its control 
information to a specific VDE node but rather carries sufficient 
control and permissions to permit its use, in whole or in part, at 
any of several sites is called a "Traveling Object" (see Figure 19). 

Objects may be classified in another sense based on the 
nature of the information they contain. A container with 
information content is called a "Content Object* (see Figure 20). 
A container that contains transaction information, audit trails, 
VDE structures, and/or other VDE controyadministrative 
information is called an "Administrative Object" (see Figure 21). 
Some containers that contain executable code operating under 
VDE control (as opposed to being VDE control information) are 
called "Smart Objects." Smart Objects support user agents and 
provide control for their execution at remote sites. There are 
other categories of objects based upon the location, type and 
access mechanism associated with their content, that can include 
combinations of the types mentioned above. Some of these 
objects supported by VDE 100 are described below. Some or all of 
the data blocks 812 shown in Figure 17 may include "embedded" 
content, administrative, stationary, traveling and/or other 
objects. 
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1. Stationary Objects 

Figure 18 shows an example of a "Stationary Object" 
structure 850 provided by the preferred embodiment. 
"Stationary Object" structure 850 is intended to be used only at 
5 specific VDE electronic apphance/installatioiis that have received 

explicit permissions to use one or more portions of the stationary 
object. Therefore, stationary object structure 850 does not 
contain a permissions record (PERC) 808; rather, this 
permissions record is supplied and/or delivered separately (e.g., 
10 at a different time, over a different path, and/or by a different 

party) to the apphance/installation 600. A common PERC 808 
may be used with many different stationary objects. 



As shown in Figure 18, public header 802 is preferably 
15 "plaintext" (i.e., unencrypted). Private header 804 is preferably 

encrypted using at least one of many "private header keys." 
Private header 804 preferably also includes a copy of 
identification elements from public header 802, so that if the 
identification information in the plaintext public header is 
20 tampered with, the system can determine precisely what the 

tamperer attempted to alter. Methods 1000 may be contained in 
a section called the "private body" 806 in the form of object local 
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methods, load modules, and/or user data elements. This private 
body (method) section 806 is preferably encrypted using one or 
more private body keys contained in the separate permissions 
record 808. The data blocks 812 contain content (information or 
5 administrative) that may be encrypted using one or more content 

keys also provided in permissions record 808. 

2. Traveling Objects 

Figure 19 shows an example of a "traveling object" 
10 structure 860 provided by the preferred embodiment. Traveling 

objects are objects that carry with them sufficient information to 
enable at least some use of at least a portion of their content 
when they arrive at a VDE node. 

Traveling object structure 860 may be the same as 
stationary object structure 850 shown in Figure 18 except that 
the traveling object structure includes a permissions record 
(PERC) 808 within private header 804. The inclusion of PERC 
808 within traveling object structure 860 permits the traveling 
object to be used at any VDE electronic appliance/participant 600 
(in accordance with the methods 1000 and the contained PERC 
808). 
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Traveling" objects are a class of VDE objects 300 that can 
specifically support "out of channel" distribution. Therefore, they 
include key block(s) 810 and are transportable from one 
electronic appliance 600 to another. Traveling objects may come 
5 with a quite limited usage related budget so that a user may use, 

in whole or part, content (such as a computer program, game, or 
database) and evaluate whether to acquire a license or further 
license or purchase object content. Alternatively, traveling object 
PERCs 808 may contain or reference budget records with, for 
10 example: 

(a) budgets) reflecting previously purchased rights or 
credit for future licensing or purchasing and 
enabling at least one or more types of object content 
usage, and/or 

15 

(b) budget(s) that employ (and may debit) available 
credit(s) stored on and managed by the local VDE 
node in order to enable object content use, and/or 

20 (c) budget(s) reflecting one or more maximum usage 

criteria before a report to a local VDE node (and, 
optionally, also a report to a clearinghouse) is 
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required and which may be followed by a reset 
allowing further usage, and/or modification of one or 
more of the original one or more budget(s). 

As with standard VDE objects 300, a user may be required 
to contact a clearinghouse service to acquire additional budgets if 
the user wishes to continue to use the traveling object after the 
exhaustion of an available budget(s) or if the traveling object (or 
a copy thereof) is moved to a different electronic appliance and 
the new appliance does not have a available credit budget(s) that 
corresponds to the requirements stipulated by permissions record 
808. 

For example, a traveling object PERC 808 may include a 
reference to a required budget VDE 1200 or budget options that 
may be found and/or are expected to be available. For example, 
the budget VDE may reference a consumer's VISA, MC, AMEX, 
or other "generic" budget that may be object independent and 
may be applied towards the use of a certain or classes of traveling 
object content (for example any movie object from a class of 
traveling objects that might be Blockbuster Video rentals). The 
budget VDE itself may stipulate one or more classes of objects it 
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may be used with, while an object may specifically reference a 
certain one or more generic budgets. Under such circumstances, 
VDE providers will typically make information available in such 
a manner as to allow correct referencing and to enable billing 
handling and resulting payments* 

Traveling objects can be used at a receiving VDE node 
electronic appliance 600 so long as either the appliance carries 
the correct budget or budget type (e.g. sufficient credit available 
from a clearinghouse such as a VISA budget) either in general or 
for specific one or more users or user classes, or so long as the 
traveling object itself carries with it sufficient budget allowance 
or an appropriate authorization (e.g., a stipulation that the 
traveling object may be used on certain one or more installations 
or installation classes or users or user classes where classes 
correspond to a specific subset of installations or users who are 
represented by a predefined class identifiers stored in a secure 
database 610). After receiving a traveling object, if the user 
(and/or installation) doesn't have the appropriate budget(s) 
and/or authorizations, then the user could be informed by the 
electronic appliance 600 (using information stored in the 
traveling object) as to which one or more parties the user could 
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